Introduction to

EMBEDDED
SYSTEMS

SHIBU KV
-1 NTRODUCTION TO· .
EMBEDDED SYSTEMS

I, .
ABOUT THE AUTHOR
Shibu has over nine years of hands-on experience in the Embedded & Real Time System domain with
solid background on all phases of Embedded Product Development Life Cycle. He holds a B-Tech
Degree (Hons) in Instrumentation & Cohtrol Engineering from the University of Calicut. He started his
professional career as Research Associate in the VLSI and Embedded Systems Group oflndia's prime
Electronics Research & Development Centre (ER&DCI-under the ministry of Information & Com-
munication Technology, Govt. oflndia) Thiruvananthapuram Unit. He has conducted research activities
in the embedded domain for Contactless Smart Card Technology and Radio Frequency Identification
(RFID). He has developed a variety of products in the Contactless Smart Card & RFID Technology
platform using industry's most popular 8-bit microcontroller-8051.
Shibu has sound working knowledge in Embedded Hardware development using EDA Tools and
firmware development in Assembiy Language and Embedded C using a variety of IDEs and cross-
compilers for various 8/16/32 bit microprocessors/microcontrollers and System on Chips. He is also an
expert in RTOS based Embedded, System
. design for various RTOSs including Windows CE, VxWorks,
MicroC/OS-II and RTX-51. He is well versed in various industry standard protocols and bus interfaces.
Presently, he is engaged with the Embedded Systems & Product Engineering practice unit of Infosys
Technologies Ltd (www.infosys.com), Thiruvananthapuram Unit.
 INTRODUCTION TO
EMBEDDED SYSTEMS

Shibu KV
Technical Architect
Mobility & Embedded Systems Practice
Infosys Technologies. Ltd.,
Trivandrum Unit, Kera/a

McGraw Hill Education (India) Private·Lfmited

NEW DELHI

McGraw Hill Education Offices

New Delhi New York St Louis San Francisco Auckland Bogota Caracas
Kuala Lumpur Lisbon London Madrid Mexico City Milan Montreal
San Juan Santiago Singapore Sydney Tokyo Toronto
■ McGraw Hm Ed~cation (India) ~rivate Limited
Published by McGraw Hill Education (India) Private Limited
P-24, Green Park Extension, New Delhi 110 016

Copyright© 2009 by McGraw Hill Education (India) Privat~ Limited.

Thirteenth reprint 2014

RACXRRYURYXZY

No part of this publication may be reproduced. or distributed in any form or by any means,
electronic, mechanical; photocopying, recording, or otherwise or stored in a database or
retrieval system without the prior written permission of the publishers. The program listings
(if any) may be entered, stored and executed in a, computer system, but they may not be
reproduced for publication.
'
Thls edition -can be exported from India only by the publishers,
McGraw Hill Education (India) Private Limited.

ISBN (13 digit): 978-0-07-014589-4

ISBN (10 'digit): 0-07-014589-X
Vice .President and Managing Director: Ajay Shukla
General Manager-!-Publishing-SEM & Tech Ed: Vibha Mahajan
Manager-Sponsoring: Shalini Jha
Associate Sponsoring Edit9r: Nilanjan Chakravarty
Development Editor: Surbhi Suman
Jr Manager-Production: Anjali Razdan
General Manager-Production: Ra/ender P Ghansela

"Infonnation contained in this work has been obtained by McGraw Hill Education (India),
from sources believed to be reliable. However, neither McGraw Hill Education (India) nor
its authors guarantee the accuracy or completeness of any information published herein, and
neither McGraw Hill Education (India) nor its authors shall be responsible for any errors, ·
omissions, or damages arising out of use of this infonnation. This work is published with the
understanding that McGraw Hill Education (India) and its authors are supplying information
but are not attempting to render engineering or other professional services. If such services are
required, the assistance of an appropriate professional should be sought.

Typeset at The Composers, 260, C.A. Apt., Paschim Vihar, New Delhi 110 063 and printed at
Sanat Printers, 312 EPIP, HSIDC, Kundli, Sonepat, Haryana ·
 . /

I dedica-te-this book to all Infoscions, my wife, my unborn kid,

my parents, my friends and my loved·on'es
Preface xiii
Acknowledgements xvii
Part 1
Embedded System: Understanding the Basic Concepts
1. Introduction to Embedded Systems 3
1.1 What is an Embedded System? 4
1.2 Embedded Systems vs. General Computing Systems 4
1.3 History of Embedded Systems 5
1.4 Classification of Embedded Systems 6
1.5 Major Application Areas of Embedded S¥Sfems 7
1.6 Purpose of Embedded Systems 8
1.7 'Smart' Running Shoes from Adidas-The Innovative Bonding of
Lifestyle with Embedded Technology 11
Summary 13
Keywords 13
Objective Questions 14
Review Questions 14
2. The Typical Embetlded System 15
2.1 Core of the Embedded System 17
2.2 Memory 28
2.3 Sensors and Actuators 35
2.4 Communication Interface 45
2.5 Embedded Firmware 59
2.6 Other System Components 60
2. 7 PCB and Passive Components 64
Summary 64
Keywords 65
 Contents

Objective Questions 67
Review Questions 69
Lab Assignments 71
3. - Characteristics and Quality Attributes of Embedded Systems 72
3.1 Characteristics ofan,EmbeddedSystem 72
3.2 Quality Attributes of Embedded Systems 74
Summary 79
Keywords 79·
Objective Questions 80
Review Questions 81 _
4. Embedded Sy$tems--Applkation- and Domairi'-Specific 83
4.1 Washing Machine-·ApplicationtSpecific Embedded System 83
4.2 Automotive - Domain-Spedfic Examples of Embedded System 85
Summary 89
Keywords 90
Objective Questions 90
Review Questions 91
5. Designing Embedded Systems with 8bit Microcontrollers-8051 92
5.1 Factors to be Considered in Selecting a Controller 93
5.2 Why 8051 Microcontroller 94
5.3 Designing with 8051 94
5.4 The 8052 Microcontroller 155
5.5 8051152 Variants 155
Summary 156
Keywords 157
Objective Questions 158
Review Questions 161
Lab Assignments 162
6. Programming the 8051 Microcontroller 164
6.1 Different Addressing Modes Supported by 8051 165
6-2 The 8051 Instruction Set 171
Summary 196
Keywords 197 ·
Objective Questions 197
Review Questions 202
Lab Assignments 203
7. Hardware Software Co-Design and Program Modelling 204
7.1 Fundamental Issues in Hardware Software Co-Design 205
7.2 Computational Models in Embedded Design 207
7.3 Introduction to Unified Modelling Language (UML) 214
7.4 Hardware Software Trade-offs 219
Summary 220
 Contents

Keywords 221
Objective Questions 222
Review Questions 223
Lab Assignments 224
Part 2
Design and Development o( Embedded Product
8. Embedded Hardware Design and Development 228
8.1 Analog Electronic Components 229
8,2 Digital Electronic Components 230
8j3 VLSI and Integrated Circuit Design 243
8.4 Electronic Design Automation (EDA) Tools 248
8.5 How to use the OrCAD EDA Tool? 249
8.6 Schematic Design using Orcad Capture CIS 249
8.7 The PCB Layout Design 267
8:8 Printed Circuit Board (PCB) Fabrication 288
Summary 294
Keywords 294
Objective Questions 296
Review Questions 298
Lab Assignments 299
9. Embedded Firmware Design and Development 302
9.1 Embedded Firmware Design Approaches 303
9.2 Embedded Firmware Development Languages 306
9.3 Programming in Embedded C 318
Summary 371
Keywords '372
Objective Questions 373
Review Questions 378
Lab Assignments 380
10. Real-Time Operating System (RTOS) based Embedded System Design 381
· 10.1 Operating System Basics 382
10.2 Types of Operating Systems 386
1OJ Tasks, Process and Threads 390
10.4 Multiprocessing and Multitasking 402
10.S Task Scheduling 404
10.6 Threads, Processes and Scheduling: Putting them Altogether 422
10.7 Task Communication 426
10.8 Task Synchronisation 442
10.9 Device Drivers 476
10.10 How to Choose an RTOS 478
Summary 480
Keywords 481
Objective Questions 483
 Contents

Review Questions 492

Lab Assignments 496
11. An Introduction to Embedded System Design with
VxWorks and MicroC/OS-II RTOS 498
II.I VxWorks 499
1i.2 MicroC/0S-II 514
Summary 541
· Keywords 542
Objective Questions 543
Review Questions 544
·Lab Assignments 546
12. Integration and Testing of Embedded Hardware and Firmware 548
12.1 Integration of Hardware and Firmware 549
12.2 Board Power Up 553
Summary 554
Keywords 554
Review Questions 555
13. The Embedded System Development Environment 556
13.1 The Integrated Development Environment (IDE) 557
1-3.2 Types of Files Generated on Cross-compilation 588
13.3 Disassembler/Decompiler 597
13.4 Simulators, Emulators and Debugging 598
13 .5 Target Hardware Debugging 606
13.6 Boundary Scan 608
Summary 610
Keywords 611
Objective Questions 612
Review Questions 612
Lab Assignments 613
14. Product Enclosure Design and Development 615
14.1 Product Enclosure Design Tools 616
14.2 Product Enclosure Development Techniques 616
14.3 Summary 618
Summary 618
Keywords 619
Objective Questions 620
Review Questions 620
15. The Embedded Product Development Life Cycle (EDLC) 621
15.1 What is EDLC? 622
15.2 Why EDLC 622
15.3 Objectives ofEDLC 622
15.4 Different Phases ofEDLC 625
 Contents

15.5 EDLC Approaches (Modeling the EDLC) 636

Summary 641
Keywords 642
Objective Questions 643
Review Questions 644
•s
16. Trends in the Embedded Industry 645
16.1 Processor Trends in Embedded System 645
16.2 Embedded OS Trends 648
16.3 Development Language Trends 648
16.4 Open Standards, Frameworks and Alliances 651
16.5 Bottlenecks 652
Appendix I: Overview of PIC andAVR Family ofMicrocontrollers and ARM Processors 653
Introduction to PIC® Family of Microcontrollers 653
Introduction to AVR® Family ofMicrocontrollers 657
Introduction to ARM® Family of Processors 664
Appendix II: Design Case Studies 669
1. Digital Clock 669
2. Battery-Operated Smartcard Reader 699
i6 3. Automated Meter Reading System (AMR) 701
4. Digital Camera 703
Bibliography 706'
Index 709

l5
There exists a common misconception amongst students and young practising engineers that embed-
ded system design is 'writing 'C' code'. This belief is absolutely wrong and I strongly emphasise that
embedded system design refers to the design of embedded hardware, embedded firmware in 'C' or other
supporting languages, integrating the hardware and firmware, and testing the functionalities of both.
Embedded system design is a highly specialised branch of Electronics Engineering where the techno 7
logical advances of electronics and the design expertise of mechanical engineering work hand-in-haQ.d
to deliver cutting edge technologies and high-end products to a variety of diverse domains including
consumer electronics, telecommunications, automobile, retail and banking applications: Embedded sys-
tems represent an integration of computer hardware? software along with programming concepts for
developing special-purpose computer systems, designed to perform one or a few dedicated functions.
The embedded domain offers tremendous job opportunities worldwide. Design of embedded system
is an art, and it demands talented people to take up the design challenges keeping the time frames in
mind. The biggest challenge faced by the embedded industry today is the lack of skilled manpower
in the domain. Though most of our fresh electronics and computer science engineering graduates are
highly talented, they lack proper training and knowledge in the embedded domain. Lack of suitable
books on the subject is one of the major reasons for this crisis. Although various books on embedded
technology are available, almost none of them are capable of delivering the· basic lessons in a simple
and structured way. They are written from a high-end perspective, which are appropriate only for the
practising engineers.
This book 'Introduction to Embedded Systems' is the first-of-its-kind, which will appeal as a com-
prehensive introduction to students, and as a guide to practising engineers and project managers. It has
been specially designed for undergraduate courses in Computer Science & Engineering, Information
Technology, Electrical Engineering, Electronics & Communication Engineering and Instrumentation
& Control Engineering. Also, it will be a valuable reference for the students of BSc l MSc / MTech
(CS/IT/Electronics), MCA and DOEACC 'B' level courses.
The book has been organised in such a way to provide the fundamentals of embedded systems;
the steps involved in the design and development of embedded hardware and firmware, and their inte-
gration; and the life cycle management of embedded system development. Chapters 1 to 4 have been
 Preface

structured to give the readers a basic idea of an embedded system. Chapters 5 to 13 have been organised
to give an in-depth knowledge on designing the embedded hardware and firmware. They would be very
helpful to practising embedded system engineers. Chapter 15 dealing with the design life cycle of an
embedded system would be beneficial to both practising engineers as .well as project managers. Each
chapter begins with learning objectives, presenting the concepts in simple language supplemented with
ample tables, figures and solved examples. An important part of this book comes at the end of each
chapter where you will find a brief summary, list of keywords, objective questions (in multiple-choice
format) and review questions. To aid students commence experimentation in the laboratory, lab assign-
ments have been provided in relevant chapters. An extremely beneficial segment at the end of the book
is the overview of PIC & AVR Family of Microcontrollers & ARM Processors as well as innovative
design case studies presenting real-world situations. ·
The major highlights of this book are as follows.
• Brings an entirely different approach in the learning of embedded system. It looks at embedded
systems as a whole, specifies what if is, what it comprises of, what is to be done with if and how
to go about the whole process o.f designing an embedded system. ,
• Follows a design- and development-oriented approach through detailed explanations for Keil Mi-
cro Vision (i.e., embedded system/integrated development environment), ORCAD (PCB design
software tool) and PCB Fabrication techniques.
• Practical implementation such as washing machines, automotives, and stepper motor and other
I/0 device interfacing circuits.
• Programming concepts: deals in embedded C, delving into basics to unravelling advance level
concepts.
• Complete coverage of the 8051 microcontroller architecture and assembly language program-
mmg.
• Detailed coverage ofRTOS internals, multitasking, task management,-task scheduling, task com-
munication and synchronisation. Ample examples on the various task scheduling policies.
• Comprehensive coverage on the internals ofMicroC/OS-II and VxWorks RTOS kernels.
• Written in lucid, easy-to-understand language with strong emphasis on examples, tables and fig-
ures.
• Useful reference for practicing engineers not well conversant with embedded systems and their
applications.
• Rich Pedagogy includes objective questions, lab assignments, solved examples and review
questions.
The comprehensive online learning centre-.http://www.mhhe.com/shibu/esle-accompanying
this book offers valuable resources for students, instructors and professionals.
For Instructors
• PowerPoint slides (chapter-wise)
• A brief chapter on Embedded Programming Language C++/ Java
• Case studies that are given in the book and one new case study on heart beat monitoring system
• Solution manual (chapter-wise)
• Short questions, quizzes in the category of fill in the blanks, true/false and multiple choice ques-
tions (25); programming questions with solution (5). (Level of difficulty: hard)
• Chapter-\vise links to important websites and important text materials
 Preface

For Students
• Chapter-wise tutorials
• A brief chapter on Embedded Programming Lang~age C++/ Java
• Case studies that are given in the book and one new case study on heart beat monitoring system
• Answers for objective questions/selected review questions and hints for lab assignments provided
in the book.
• Short questions, self-test quizzes in the category of fill in the blanks, true/false and multiple choice
questions (25); programming questions with solutions (5). (Level of difficulty: easy/medium)
• List of project ideas
• Chapter-wise links to important websites and important text materials.
This book is written purely on the basis of my working knowledge in the field of embedded hardware
and firmware design, and expertise in dealing with the life cycle management of embedded systems.
A few descriptions and images used in this book are taken from websites with prior written copyright
permissions from the owner of the site/author of the articles.
The design references and data sheets of devices including the parametric reference used in the. il-
lustrative part of this book are taken from the following websites. Readers are requested to visit these
sites for getting updates and more information on design articles. Also, you can order some free samples
from some of the sites for your design.
www.intel.com Intel Corporation
www.max1m-1c.com Maxim/Dallas Semiconductor
www.atmel.com Atmel Corporation
www.analog.com Analog Devices
www.microchip.com Microchip Technology
www.ti.com Texas Instruments
www.nxp.com NXP Semiconductors
www.national.com National Semiconductor
www.fairchildsemi.com Fairchild Semiconductor
www.intersil.com Intersil Corporation
www.freescale.com Freescale Semiconductor
www.xilinx.com Xilinx (Programmable Devices)
www.orcad.com Cadence Systems (Orcad Tool)
www.keil.com Keil (MicroVision 3 IDE)
www.embedded.com Online Embedded Magazine
www.elecdesign.com Electronic Design Magazine
I would be looking forward to suggestions for further improvement of the book. You may contact me
at the following email [email protected]. Kindly mention the title and author name in
the subject line. Wish you luck as you embark on an exhilarating career path!
Shibu KV
I take this opportunity to thankMr Mohammed Rijas (Group Project Manager, fyfobility and Embedded
Systems. Practice, Infosys Technologies· Ltd Thiruvananthapuram) and Mr Shafeer Badharudeen
(Senior Project Manager, Mobility and Embedded Systems Practice, Infosys Technologies Ltd
Thiruvananthapuram) for their valuable suggestions and guidance in writing this book. I am also grateful
to,my team and all other members of the Embedded Systefi1:s Group, Info~s Technologies for inspiring·
me to write this book. I acknowledge my senior management team at the Embedded Systems and
Mobility practice, Infosys Technologies-Rohit
.
P, Srinivasa Rao M, Tadimeti Srinivasan, .Darshan .;

Shankavaram and Ramesh Adiga-for their constant encouragement and appreciation of my efforts.
I am immensely grateful to Mr R Ravindra Kumar (Senior Director, CDAC Thiruvananthapuram) for
giving me an opportunity to work with the Hardware Design Group of CDAC (Erstwh1le ER&DC---I),
Mrs K G Sulochana (Joint Director CDAC Thiruvananthapuram) for giving ~e the first embedded
project to kick start my professional career and also for all the support provided to me during my tenure
with CDAC. I convey my appreciation to Mr Biju C Oommen (Addl. Director, Hardware Design Group,
CDAC Thiruvananthapuram), who is my great source of inspiration, for giving me the basic lessons of
embedded technology, Mr S Krishna Kumar Rao, Mr Sanju Gopal, Ms Deepa RS, Mr Shaji NM and
Mr Suresh R Pillai for their helping hand during my research activities at CDAC, and Mr Pniveen V L
whose contribution fo designing the graphics of this book is noteworthy. I extend my heartfelt gratitude
to aUmy friends and ex-colleagues of Hardware Design Group CDAC Thiruvananthapuram-without
their prayers and support, this book would not have been a reality. Last but not the least, I acknowledge
my beloved friend Dr Sreeja for all the moral support provided to me during this endeavor, and my
family members for their understanding and support during the writing of this book.
A token of special appreciation to Mr S Krishnakumar Rao (Deputy Director, Hardware Design
Group, CDAC Thiruvananthapuram) for helping me in compiling the section on VLSI Design and
Mr Shameerudheen P T for his help in compiling the section on PCB Layout Design using Orcad
Layout Tool.
 Acknowledgements

I would like to extend my special thanks to the following persons for coordinating and providing
timely feedback on all requests to the concerned product development/service companies, semiconductor
manufacturers and informative web pages.
Angela Williams of Keil Software
Natasha Wan, Jessen Wehrwein and Scott Wayne of Analog Devices
Derek Chan of Atmel Asia
Moe Rubenzahl of Maxim Dallas _Semiconductor
MarkAaldering and Theresa Warren of Xilinx
Anders Edholm of Electrolux
Vijayeta Karol of Honda Siel Cars India Ltd
Mark David of Electronic Design Magazine
Vidur Naik of Adidas India Division
Steven Kamin of Cadence Design Systems
Deepak Pingle and Pralhad Joshi of Advanced Micronic Devices Limited (AMDL)
Regina Kim of WIZnet Inc.
Taranbir Singh Kochar of Siemens Audiology India Division
Crystal Whitcomb of Linksys-A Division of Cisco Systems
Kulbhushan Seth of Casio India Co. Pvt. Ltd
Jitesh Mathur and Meggy Chan of Philips Medical Systems
John Symonds of Bum Technology Limited
Citron Chang of Advantech Equipment Corp
Michael Barr of Netrino Consultants Networks
Peggy Vezina of GM Media Archive
David Mindell of MIT
Frank Miller of pulsar.gs
Gautam Awasthi of Agilent Technologies India Pvt. Ltd
A note of acknowledgement is due to the following reviewers for their valuable suggestions for the
book.
Bimal Raj Dutta
Shri Ram Murti Smarak College of Engineering & Technology, Bareilly
Nilima Fulmare
Hindustan College of Science & Technology, Agra
PK Mukherjee
Institute of Technology, Banaras Hindu University, Varanasi
Kalyan Mahato
Government College of Engineering & Leather Technology, Kolkata
P Kabisatpathy
College of Engineering & Technology, Bhubaneswar
PK Dutta
North Eastern Regional Institute of Science and Technology College, Itanagar
 Acknowledgements

Prabhat Ranjan .
Dhi.rubhai Ambani Insiitute of Information and Communication Technology (DAIICT), Gandhinagar
LylaB Das
National Institute of Technology Calicut (NITC), Calicut
Finally, I thank the publishing team at McGraw-Hill Education India, more specifically Vibha Mahajan,
Shalini Jha, Nilanjan Chakravarty, Surbhi Suman, Dipika Dey, Anjah Razdan and Baldev Raj for their
praiseworthy initiatives and efficient management of the book.
SmBuKV
'I'

~-
: . •• • • • • • • • • • .. • .. • • • .. • •· • • · • • ~ .. • • • • · • • • • .. · • ( Learning Objectives )
,;'Q;l. XLEAl!NING OBJEC'rIVES • .

. ..
···················································

( Sections and Suh-sections ) ...•..•....,. ...................................... , •..

: :-~~:z,,:~:~Jt_OSf~~~C~QN~;;J;~. --~;~;~'; -::~. it:~:;'.~-~-_;/;2':t;.:~~~~f;:};·?~- :~: ~- ~
As mentioned earlier, !he 8051 lnstruclion Set is broadly classified into five categories namely~ Data
transfer insfructions. Arilhmelic instn,clions, Lcgical instructions, Boolean instructions and Program
control transfer instrucllons. The following sections describe _each of them in det;ail

, 6.2 .1 Data Transfer Instructions

• Data transfer instruclions transfer data between a source and destination. The source can be an internal
data memory, a register, external data memory. code memory or immediate data. Destination may be an •
internal daia memory, external data memory or a regist~r,
• 6.2.1.1 Internal Data Transfer Operations lnlemal data transfer instructions perform the move~
ment of da,ta between, register, memory loca1ion, accumulator arid stack. MOV inslruction is used for
data transfer between register, memory location and accumulator. PUSH and POP mstructions transfer

. .
• data between memory location/register and stack, The following table summarises the various mtemat :
• data transfer mstructlons •

···················································
:
····················································
[ Example l ] •~
The accumulator P!gistet con1:iins SOH and B register comams &fH. Add m;umufator cor:.tcnt wilh B rcg1slcr. Explain •
• tile output ofthc summation and the s!rn.uiofthc carry fla£ alter the addi11onopcration (,......;•:...-----------.)
i\ddmg $OH w11h 8FH rt"Sul!s in \OHL Since IOFH «:quires more than 8 bils 10 repr.:so:n1, !he accumulator holds

•
:~:!~~\ !~~:~:~~~~~ l~~soo~;~ :~~! ~~~~;l~!~~~~o~:i;~~~ ~:Sue~~~ ~::i:~: ~~~F~~~ ~~~i!~~r Solved Examples
the addiflon op.:rauon and the involvement ofC,1rry bi! tC'Y}

801-1
..................................................
ADOt\.8 Provided at appropriate locations,
SFH
Solved Examples aid in
OFH understanding of the fundamentals
~!:!._!) llh.1,U"-"tlOn of ADD lnatruction op~ra~Oll
of embedded hardware and firmware
design.
. ~rnI>l::,C)
• RezJs1cr RO rnnwin.~ OHH. Add the rnnlcnts of register IHI with the sur.. obtam,:d in the previous c-,;ampl,: u~mg ADDC
.•
•
•• ~lnlil~if ~>;t!:,~1 !t:; c~t~t.~o'1~e !u~1r:;a~o~ a_:1~u:.e !1a!u~ o! t~e i~.ft!g:~er•tn; 1:~t~-;.o~e~al~r~ • • • • • ••
 (- -Photographs ••••
) ome emueaue d•• - ••s1orc
syslcms - .........
me co11cc1ca,. aata
L. . . . . ,. • "xor•processing
• • • • • •ani:I
• •ana1ys1s.
• - ........ ,, • ·-mcor-
;::,ucn systems ••• •
- - - - - - - - - - ate a built-in/plug-in storage memory for storing the captured data. Some of them give the user a ••
• meaningful rcprescnlatlon of the collected data
• by visual (graphical/quantitative) or audible
• means using display units [Liquid Crystal Dis-
• \~t~e-:• • • -: • e, • • •·• • !·• • • • •·• • • • • • • • • • • • •·• • • • • • • •·• ·•··• • • • -: play (LCD), Light Emitting Diode (LED), etc.)

:jj ~#illa!liJJlf 1' '.

•
~i~~~{~
A digital camera is a typical example of an
embedded system with data colliction/storage/
representation of data. Images are captured and
• the captured image may be stored within the
memory of the camera. The captured image can
also be presen!ed to the user through a graphic
LCD unit. .

1.6.Z Data Communication

Embedded data co.mmunlcalll;m systems are deployed in
applicatioits:ranging from complex ·satellite communi-
• cation systems to simple home networking systems. As
• mentioned earlier in this chapter, the data collected by an
embedded terminal may require transferring of the same -
• to some other system located remotely. The transmission
• is achieved either by a wire-line me4.ium or by a wire-
less medium. Wire-line medium was the most common
choice in all olden days embedded systems. As technolo-
• gy is changing, wireless medium is becoming the de-facto
: standard for data communication in embedded systems.
• A wireless medium offers cheaper connecllvity solutions
• and make the communicalion link free from the hassle of
: wire bundles. Data can either be transmitted by analog
means or by digital means. Modem industry trends are [ Fig."1.2) i~~~,~~~i:,ic.ro11te-rfo.i_da.la
settling towards digital communication. comm.Wcallon. .. _. ,
(Phoiit~ety'orf1nsaµ

...
•
The data collecting embedded tennir.al itself can

..
incorporate data communication units like wireless
,,
(~lin.1::5#-"COmfA d'MSion o/GSCO
sr,s-rem)·;<'

··········~·····-·································
••••••••••••••••••••••••••••••••••••• • •••••• •·w.1
• Designing Erp.bedded Systems with 8bit Microcontrollers~OSI ti-- •••
PO.OloP0.7 P2.010P2.7

( Illustrations )
..······~······•.~·····•·!••·····~~~····~~·············••.•
,SEN\
ALEA'ROGI
EA\M'P
RST
RD\
WR,

PL010Pl.1 rJ.OioPJ.7

• ( Fig. 5.1} 8051 Arc:hitechUe--Bloc:k diagtun repres6ntaUon

5 .3 .Z The Memory Organisation

8051 1s built around the Han•ard proces~or arctiitecture. 111c progr;:im and data memory of 8051 is
logically separated and they.physically reside separately. Separate address spaces arc assigned for data •
memory and program memory. 805/'s address bus is 16bit wide and it can address up to 64KB (2 16)
• memory.
• 5.3.2.1 The Program (Code) Memory The basic 80j/ architecture provides lowest 4K bytes •
of program memo[)' as on-chip memory (bmlt-in chip memOI')'). In 8031, the ROM less counterpart of
8051, all program memo!')' 1s external to the chip. Switching between lhe internal program memory and
• external program memory ts accomplished by changing the log,c level of the pin External Access (EA\)
Tying EA\ pin lo logic I U'cc), configures the chip lo execute instructions from program mcmorx._ up to •
4K (program memory location up to 0FFFH) from internal memory and 4K (program memOI')' location
• from I000H) onwards from external memory, while connecting EA\ pin lo logic 0 (GND) configures !he
• chip to external program execution mode, where the entire code memory is executed from the external •
• memory. Remember External Access pin 1s an active low pm (Normally referred as EA\). The control

.................................................
•• .signal for e:ttemal program memo!')' execution is PSEN\ (Program S1robe Enable). For internal program •:
 ( Chapter Summary and Keywords )' · · · · • • · · · ········di•~=~:•;••···•••••_·····•·····•~
Sf~ i~ ~)~tectronic/Etcctr~m~:ka1_;~~ ~~\gned to perform _a-~ille ~µon~ i.s •

......

.· .............. ·;a· ........................... ···.

• !--------- •
:_Objective Questions ]
I Embedded systems are
(a} Gener.i:l prnpose (b} Special purpos.e
2, Embedded system is
(a) An electronic system (b) A ptm: mechanical system
(e} Ancleciro-mechanica!system (d) (a)or(c)
J Which of the following is not true abou! embedded systems? . ,
(a) Built around specialised hardware
(c) Execotlon behaviour may be determin1st1c
(b) Always contain an operat1r,,g system
(d} All of these
( Objective and Review Questions )
(e) None of these

..································~·~················~
4, Which of the followmg 1s not an example ofa 'Small-scale Embedded System''J
(a) El~tronieBarb1edoll (b) Simpleolculator
(c) Ccll phone (d) Elec1ronic toy car
5 11;c ii~ recognised modem embedded system i:.
{a) Appl<! Computer (b} Ap~J!o Ou1danc1: Computer (AOC;
(c) "talcula!or
6 The first mass prodll{;edcmbrrld:d syslcm is
{d} Radio Navigation System
Readers can assess their:knowledge
(a) Mmuteman-1 (b} Min11temon,H
{c) Au1one:11cs D-17 (d) Apollo GuidanC\! Computer (AGC)
7 Which oftbe fol!owmg. is (arc) an Intended purpose(s} of embedded systems?
by answering the Objective
(a} Datil cotlceuon
(dj AU of these
(b) Data processing
(c) Nooe of these
(c} Da!a commumca11on
Questions in multiple--:choice
Which of !be followmg is an (are} examplc(s) ofembcd({e<l system for data comrmmicatton?
(al lJSB Mass storage device (b) Network router format. Review Questions spur
(c) Drgital camera (d) Music player
i):) A!loflhese (f) Noni:.of1hrn.:
A d1gl1al multi mekr is an e:rnmplc of an embcddCJJ system fo~
students to apply and integrate
(a) Da!a communicatton
(c) Noneofthcsc
(h) Mom1oiint (c} Con1rol (d) All oflhcse
chapter content.
10 Which of the folkt,vmt; 1s an {arc} example(s) ofrm er.ih.:Jdcd 5:·s1cm for sign.ii procc:ssm~~
(a) Apple irOD (media player device) (b) S.:mD:sk USB mas!. smrag:c dmce
(c} Bolh (a) and (b) (d) Non:e of these

c~','Z{?,i,_
d½ -Review
----~-~
Questions I
I Whal 1s :m ~mbcdded sysiem'.' faplain !he <liiTcrcnt appl1catmns of embedded systems:

.. 2. fap!ain the various purposes of embedded systems m detail wtth illustrative e,,;amples
J EX.plain the diffcrt.'tlt elassifica11ons of crnbcrldcd systems. Give un e;,;ample for each

···················································
 ( Lah Assignments
}···············································.
l:U Lah .l!..ssignments ) ~
" "• ~· '

b 'Write il 'C'._.prQ,gta91 to-find thc,ffldiaM_w' <0-f.~·proc~or. tn•Whlch the program inunning. l f l h e ~ t

. •
, isbig·M~ats,:print~·~arerurictw:eisBig.~ah';el$eprinl ..l"bc~archituiureis'litlle
' ' , · ' _cpro~.:~ly,on a PC·with \Vmd01,1,-s,).,inux and MAC
. . . -
2. ~rl Ji]n. of a mi~ller. The LgD ~'tuhyt:d. ()l'!
tfte tft5i~requi~to ~·~;crinwilh lhC

l, · ,~·;,ufiw~oi~,nJldivclo;;Power-6n..,.,p,i,,,ofwid!h
• ' 2,/_ ·-~· ·, ·~}·~
• 4.•,- _ , .. ti;isedcbro~n;out·'ptote,ctloif CUcuit with active lo\~·~ pUOO for !he •
♦♦ • • /~1~~,1f:S!~~-/ ~~~••• ♦ ♦ • • •-• •·• • ♦ • •·• • ♦ • • ♦ • • • • • ♦ • • • • • ♦ • • •

. ...........................................
~,~,,-

Case Studies

r. ·,·. ·t~t'{;~:t~,::o~:~;;.• ~:··.

.
~/-~~ ~~- •~,~ ~· •,•~· •• ~ ••••••:,!
'.;iii
.;ii.
,'
Design and bnplement a lJigi1al Clock as pet the requirements given below,
I. Use a l6charactcr 2-line display fordisplaylng the cuirent1ime. Display the lime in DAY lffi:MM:SS fonnal •
i;,.
on the first line. Display the message 'Have ANice Day!' on tl'k: second line, DAY n:presents: the day oflhe Weck •
(SUN,MON. TUE, WED, nru. FRJ and SAT}. HHrcpresentsthe hourln2 digit fbrmat Depending on th<Jormat •
settingsitmayVarJfrom OO!o 12(12 Hour Format}orfromOOto 23{24 Hour formal). MM representslheminule •
m 2 digit format it varies from 00 to 59. SS represents theSetOnds in 2 digit format. It varies from 00 to S9. Tht •
alignment of display character should be centre justified (Meaning if the char.sclers lo display are 12, pack it with
2 blank space each at right and left and then display).
2. lnlerfacc. a Hitachi HD447i0 compatible LCD wilh SOS I mkrocontroller as p<::r the following interface de!ails
Data:'Bus; Port P2
Rcgisier Sci eel Control line (RS): Port Pin Pl.4
Read/Write Control Signal (RW} Port Pin Pl.:S
LCD En,ble (E): Pl.6
3. The Ba<:k!ight orth.e LCD should be always ON
4. Use AUKSJ/52 or AU9S82S2 mictocontrollcr. Use a cry:.tal Oscillator with frequency 12.00 MHz.
This will Provide ae<:urate liming or I microsecond/machine eyelc, •
5. A2 x2matrix key boud(4 keys) isintcrfoced to Pon Pi of the microcontroller. The key details are MENU key •

-~
cOMeaed to Row 0, and Colt1mn Oof lhe rnatrix.; ESC key eonnec1ed to Row o, and Colutnn 1 of lhe matrix, •
UP k.ey connected to Row l, and Cotumn Oof the m:nri:.:; DOWN J.:ey connected to Row t, 8t'ld Column 1 of th< •
• matri.'<.. The Rows 0, I Md columns 0, l of matrix keyboatd are lll!erfaccd to Port pins Pl.0, Pl.I, PL2 and Pl3 •
~ ~ • i· .ia•~',l"JIM :W'l."li"~'•' ffl '//0l1i bl ldil''l'l/'J~~ '1.1'.i''M' i 0,•wi.1l•i1i"f lf'i'i 'i •av~kidi4 • : .,.i~•···························~··············. .

Appendix on different family of

Microprocessors and Controllers

INTRODUCTION ro PIC® FAMILY or MICRO CONT.ROLLERS

........••...•........••••••..•.................. ~
. PIC'K)is a popular SJl6/J2 bit RISCm1crocontrollcr family from Microchip Technology {www.micr9ch11,._nv,n}. The 8b1t
PIC famlly comprises: lhe products PIC!Of, PICl2F, PICl6F and PICl8f They differ in lht ,amount of program memory
supported, p1.-rformance-, ins1n1c1ion Ieng!!\ and p111 count 8:ised on the architecture, the Jbi1 PIC family 1s gmup.:.d m!o
•

The Appendix section is intended throe namely,

• Baseline Products b;:m:tl o:. lhc original PIC architcctme T11c7 !t:1pp0rt 12bit 11111ruct1on it! mlb \'i:ry h■ 11cd W111- •
to give an overview of PIC & AVR •
•
tum They are anifable in 6 io 40 pin packages. ll!c 6 pin IOF JCcics, :mi:.c llf ~ric:s {8 pin t2F62'J) 111i.d 10111.: l6F
S1:ries (The 20-pin !6F690 and 40-pin l6F887) falls under 1his ca1cg:Of)' •

family of microcontrollers & ARM •

•
Mid-Range This is an cx1em;ton to the baseline a::chiteclllre wnb added fc.i!iurcs like supp0!1 for io:cr111p". oa-dup
peripherals (Like MD converter, Sena! interfaces, LCD interface, etc.}. increased memory, etc, The instru::1i110 1cl b
•

processor. •
•
•
lhis architeclure- is l4blt wide, They arc a\·ai!abk in 8 to 64 pin parkns~s with opcralmg YOllage ln t..ic r;rngc 1.8V 10
5.5V. S0me prnducts of the !2F (TI1e S prn 12F629) and lh<: l6F {'.W-pin 16F690 and 40-pfo l6FSS7) scncs comes unckr
1hise;1tegor;
•

Righ Performance The PIC l BF J and K sen es comes under this category Th..- memory density for these devices •
1s ,cry tugb (Up to 128KB program memory and 4KB data memory). They provide built~m 5'.lpport for adl-·;mcOO pcriph• •
ernls and commumcauon 1mcrfoccs like USFJ, CAN. etc fhe mstruttlon se! for tl11s an:hilccturc 1s 16bit wufo nicy me •
capable ofdcl!vermga-speedof 16MIPS.
As men!ioned earlier we have a bunch of devices to select for out desiwi, from :he PJC 8bit fami!v. Some oflhcm have
• hr:1i!cd sci of i/0 capab\litics, on-dup Peripherals, dat~ memory {SRAM} and progr~-n memory (Fi.ASH) target mg )ov, :
• er.d appltcnuons The l 2F~OS eomroller is a typical example for !his:. h eomains 511 :x 12 bi!s of program memory, '15 •
• bytes of RAM, 6 lfO Jines Md comes in an 8-pin package. On the other hand some of1he PIC family devi,:csare fc;iture
• or
rich. w11h a bunch on-chip peripherals (Like ADC. UART, l2C, SPI, etc.), higher d.Jla and program storage memo:y,
• largctingblghend applications. The 16F877 eonttollc'ris a typical ex;implc for this. II com;1ms &192 x 1-1 bils ofFLASH
• program memory, .3,68 bytes of RAM, 2S6 bytes ofF.EPROM. JJ 1/0 Imes, On-chip perlpber~ls lib: IO•bil AID converter, •
• l•1imerunn.s, USART, Interrupt Controll.:r, etc. h eornc1 rna40-pin packagt! •
•••.::r:; i;,.':~!:~~:~i:!:~;'i;!;~:~~:a: !o~,l~us~r:l!:g .lh: g:n;~c :1~ :,:;:~u;,:1:u:e :~·'•'l~us; ••
 Understanding the basic concepts is essential in the learning of any subject. Designing an Embedded
System is not a herculean task if you know the fundamentals. Like any general computing systems,
Embedded Systems also possess a set of characteristics which are unique to the embedded system under
consideration. In contrast to the general computing systems, Embedded Systems are highly domain and
application specific in nature, meaning; they are specifically designed for certain set of applications in
certain domains like consumer electronics, telecom, automotive, industrial control, measurement sys-
tems etc. Unlike general computing systems it is not possible to replace an embedded system which is
specifically designed for an application catering to a specific domain with another embedded system
catering to another domain. The designer of the embedded system should be aware of its characteristics,
and its domain and application specific nature.
An embedded system is an electrical/electro mechanical system which is specifically designed for an
application catering to a specific domain. It is a combination of specialised hardware and firmware (soft-
ware), which is tailored to meet the requirements of the application under consideration. An embedded
system contains a processing unit which can be a microprocessor or a microcontroller or a System on
Chip (SoC) or an Application Specific Integrated Circuit (ASIC)/Application Specific Standard Product
(ASSP) or a Programmable Logic Device (PLD) like FPGA or CPLD, an I/O subsystem which facili-
tates the interfacing of sensors and actuators which acts as the messengers from and to the 'Real world'
to which the embedded system is interacting, on-board and external communication interfaces for com-
municating between the various on-board subsystems and chips which builds the embedded system and
external systemiffo'."'which the embedded system interacts, and other supervisory systems and support
units like watchdog timers, reset circuits, brown-out protection circuits, regulated power supply unit,
clock generation circuit etc. which empower and monitor the functioning of the embedded system. The
design of embedded system has two aspects: The hardware design which takes care of the selection of
the processing unit, the various I/O sub systems and communication interface and the inter connec-
tion among them, and the design of the embedded firmware which deals with configuring the various
sub systems, implementing data communication and processing/controlling algorithm requirements.
Depending on the response requirements and the type of applications for which the embedded system
is designed, the embedded system can be a Real-time or a Non-real time system. The response require-
ments for a real-time system like Flight Control System, {J.irbag Deployment System for Automotive etc,
are time critical and the hardware and firmware design aspects for such systems should take these into
account, whereas the response requirements for non-real time systems like Automatic Teller Machines
(ATM), Media Playback Systems etc, need not be time critical and missing deadlines may be acceptable
in such systems.
Like any other systems, embedded systems also possess a set of quality attributes, which are the
non-functional requirements like security, scalability, availability, maintainability, safety, portability etc.
The non-functional requirements for the embedded system should be identified and should be addressed
properly in the system design. The designer of the embedded system should be aware of the different
non-functional requirement for the embedded system and should handle this properly to ensure high
· quality.
This section of the book is dedicated for describing the basic concepts of Embedded Systems. The
chapters in this section are organised in a way to give the readers a comprehensive introduction to 'Em-
bedded Systems, their application areas and their role in real life', 'The different elements ofa typical
Embedded System', the ba~ic lessons on 'The characteristics and quality attributes of Embedded Sys-
tems', 'Domain and Application specifi,c usage examples for EmbeddedSystems' and the 'Hardware and
Software Co-design approach for Embedded System Design', and a detailed introduction to 'The archi-
tecture and programming concepts for 8051 Microcontroller - The 8bit Microcontroller selected for our
design examples'. We will start the section with the chapter on 'Introduction to Embedded Systems'
d

d
n

lS
n

n
t-
d
n

L-
/'
l-
d
rt
t,
e
tf

lS

0
'S
Our day-to-day life is becoming_ more and more dependent on "embedded systems" and digital
e techniques. Embedded technologies are bonding into our daily activities even without our knowledge.
Do you know the fact that the refrigerator, washing machine, microwave oven, air conditioner, televi-
e sion, DVD~players, and m~sic systems that we use in our home are built around an embedded system?
You may be traveling by a.'Honda' or a 'Toyota' or a 'Ford' vehicle, but have you ever thought of the
d genius players working behind the special features and security systems offered by the vehicle to you? It
Lt is nothing bl!t an intelligent embedded system. In your vehicle itself the presence of specialised emb~d-
h ded systems vary from intelligent head lamp controllers, engine controllers and ignition control systems
to complex air bag control systems to protect you in case of a severe accident. People experience the
e power of embedded systems and enjoy the features and comfort provided by them. Most of us are to-
tally unaware or ignorant of the intelligent embedded systems giving us so much comfort and security.
rl Embedded systems are like reliable servants-they don't like to reveal their identity and neither they
complain about their workloads to their owners or bosses. They are always sitting in a hidden place and
d are dedicated to their assigned task till their last breath. This book gives you an overview of embedded
systems, the various steps invo,lved in their design and deyelopme,nt a!Q.d the major domains where they
r are deployed.
 Introduction to EIT!bedded Systems

An embedded system is an electronic/electro-mechanical system designed to perfo:hn a specific function

and is a combination of both hardware and firmware (software).
Every embedded system is unique, and the hardware as well as the firmware is highly specialised to
the application domain. Embedded systems are becoming an inevitable part of any product or equip-
ment in all fields including household appliances, telecommunications, medical equipment, industrial
control, consumer products, etc.

The computing revolution began with the general purpose computing requirements. Later it was realised
that the general computing requirements are not sufficient for the embedded computing requirements.
The embedded computing requirements demand 'something special' in terms of response to stimuli,
meeting the computational deadlines, power efficiency, limited memory availability, etc. Let's take the
case of your personal computer, which may be either a desktop PC or a laptop PC or a palmtop PC. It
is built around a general purpose processor like an Intel® Centrino or a Duo/Quadt core or an AMD
Turion™ processor and is designed to support a set of multiple peripherals like multiple USB 2.0
ports, Wi-Fi, ethemet, video port, IEEE1394, SD/CF/MMC external interfaces, Bluetooth, etc and with
additional interfaces like a CD read/writer, on-board Hard Disk Drive (HDD), gigabytes of RAM, etc.
You can load any supported operating system (like Windows® XPNista/7, or Red Hat Linux/Ubuntu
Linux, UNIX etc) into the hard disk of your PC. You can write or purchase a multitude of applications
for your PC and can use your PC for running a large number of applications (like printing your dear's
photo using a printer device connected to the PC and printer software, creating a document using Micro-
soft® Office Word tool, etc.) Now let us think about the DVD player you use for playing DVD movies.
Is it possible for you to change the operating system of your DVD? Is it possible for you to write an ap-
plication and download it to your DVD player for executing? Is it possible for you to add a printer soft-
ware to your DVD player and connect a printer to your DVD player to take a printout? Is it possible for
you to change the functioning of your DVD player to a television by changing the embedded software?
The answers to all these questions are 'NO'. Can you see any general purpose interface like Bluetooth or
Wi-Fi on your DVD player? Of course 'NO'. The only interface you can find out on the DVD player
is the interface for connecting the DVD player with the display screen and one for controlling the
DVD player through a remote (May be an IR or any other specific wireless interface). Indeed your
DVD player is an embedded system designed specifically for decoding digital video and generat-
ing a video signal as output to your TV or any other display screen which supports the display inter-
face supported by the DVD Player. Let us summarise our findings from the comparison of embedded
system and general purpose computing system with the help of a table:

A system which is. a combination of a generic hardware A system which is a combination of special purpose
and a General Puipose Operating System for executllig a hardware and embedded OS for executing a· specific set
variety of applications , · ,of .applications · ·
· .- •-- ,_:-_ .._,. · \~,... , . ·_:,. -- ~.:_:,:~:¥·t,:---~-~-~'!-~i;i_;i,.,..:."·-".".":,.....-":::-•,:f;,,(r<-_..,;;\:\· -:-i·~ ·"'?··"',~--·,--_._ :_·-•,~:- fi:-r~·- •,:,;·
:-· ;::",\~-:,1_,--::.:1;:1.\;:;_;,,.~~/~-~-;f--:;c:r~I~.; ___ ·> _ -r. ri. -."\"·'.?~;
-:.-~-,-::·

Contains' a Genera;l P~~~~:9perflting .• · (Gf<.t~f; :'IM.ay~:ior 'IQay 'ng1 :Contain an operati!fg

. . , : .'/ .·~./,, ·. •.· <: ,'.."'·\: ,;\{imcticmirig ·.. ij. :~:: : :: ~·., .' ·-:· ,:•::?'

tThe illustration given here is based on the processor details available till Dec 2008, Since processor technology is undergoing rapid
changes, the processor names mentioned here may not be relevant in future.
 Introduction to Embedded Systems

However, the demarcation between desktop systems and embedded systems in certain areas of
embedded applications are shrinking in certain contexts. Smart phones are typical examples of this.
Nowadays smart phones are available with RAM up to 256 MB and users can extend most of their
desktop applications to the smart phones and it waives the clause "Embedded systems are designed for
a specific application" from the characteristics of the embedded system for the mobile embedded device
category. However, smart phones come with a built-in ~perating system and it is not modifiable by the
end user. It makes the clause: "The firmware of the embedded system is unalterable by the end user", ·
still a valid clause in the mobile embedded device category.

Embedded systems were in existence even before the IT revolution. In the olden days embedded systems
were built around the old vacuum tube and transistor technologies and the embedded algorithm was
developed in low level languages. Advances in semiconductor and nano-technology and IT revolution
gave way to the development of miniature embedded systems. The first recognised modem embedded
system is the Apollo Guidance Computer (AGC) developed by the MIT Instrumentation Laboratory for
the lunar expedition. They ran the inertial guidance systems of both the Command Module (CM) and .
the Lunar Excursion Module (LEM). The Command Module was designed to encircle the moon while
the Lunar Module and its crew were designed to go down to the moon surface and land there safely. Th~
Lunar Module featured in total 18 engines. There were 16 reaction control thrusters, a descent engine
and an ascent engine. The descent engine was 'designed to' provide thrust to the lunar module out of
the lunar orbit and land it safely on the moon. MIT's original design was based on 4K words of fixed
memory (Read Only Memory) and 256 words of erasable memory (Random Access Memory). By June
1963, the figures reached 1OK of fixed and lK of erasable memory. The final configuration was 36K
words of fixed memory and 2K words of erasable memory. The clock frequency of the. first microchip
proto model used in AGC was 1.024 MHz and it was derived from a 2.048 MHz crystal clock. The
computing unit of AGC consisted of approximately 11 instructions and 16 bit word logic. Around 5000
ICs (3-input NOR gates, RTL logic) supplied by Fairchild Semiconductor were used in this design. The
user interface unit of AGC is known as DSKY (~isplay/keyboard). DSKY looked like a calculator type
keypad with an array of numerals. It was used for inputting the commands to the module numerically.
 Introduction to Embedded Systems

The first mass-produced embedded system was the guidance computer for the Minuteman-I mis-
sile in 1961. It was the 'Autonetics D-17' guidance computer, built using discrete transistor logic and a
hard-disk for main memory. The first integrated circuit was produced in September 1958 but comput-
ers using them didn't begin to appear until 1963. Some of their early uses were in embedded systems,
notably used by NASA for the Apollo Guidance Computer and by the US military in the Minuteman-II
intercontinental ballistic missile.

It is possible to have a multitude of classifications for embedded systems, based on different criteria.
Some of the criteria used in the classification of embedded systems are:
1. Based on generation
2. Complexity and performance requirements
3. Based on deterministic behaviour
4. Based on triggering.
The classification based on deterministic system behaviour is applicable for 'Real Time' systems.
The application/task execution behaviour for an embedded system can be either deterministic or non-
deterministic. Based on the execution behaviour, Real Time embedded systems are classified into Hard
and Soft. We will discuss about hard and soft real time systems in a later chapter. Embedded Systems
which are 'Reactive' in nature (Like process control systems in industrial control applications) can be
classified based on the trigger. Reactive systems can be either event triggered or time triggered.

1.4. l Classification Based on Generation

This classification is based on the order in which the embedded processing systems evolved from the
first version to where they are today. As per this criterion, embedded systems can be classified into:
I .4. I. I First Generation The early embedded systems were built around 8bit microprocessors
like 8085 and Z80, and 4bit microcontrollers. Simple in hardware circuits with firmware developed in
. Assembly code. Digital telephone keypads, stepper motor control units etc. are examples of this.
1.4.1.2 Second Generation These are embedded systems built around 16bit microprocessors and
8 or 16 bit microcontrollers, following the first'generation embedded systems. The instruction set for
the second generation processors/controllers were much more complex and powerful than the first gen-
eration processors/controllers. Some of the second generation embedded systems contained embedded
operating systems for their operation. Data Acquisition Systems, SCAD A systems, etc. are examples of
second generation embedded systems. \
1.4.1.3 Third Generation With advances in processor technology, embedded system developers
started making use of powerful 32bit processors and 16bit microcontrollers for their design. A new con-
cept of application and domain specific processors/controllers like Digital Signal Processors (DSP) and
Application Specific Integrated Circuits (ASICs) came into the picture. The instruction set of processors
became more complex and powerful and the concept of instruction pipelining also evolved. The proces-
sor market was flooded with different types of processors from different vendors. Processors like Intel
Pentium, Motorola 68K, etc. gained attention in high performance embedded requirements. Dedicated
embedded real time and general purpose operating systems entered into the embedded market. Embed-
ded systems spread its ground to areas like robotics, media, industrial process control, networking, etc.
 Introduction to Embedded Systems

1. 4.1. 4 Fourth Generation The advent of System on Chips (SoC), reconfigurable processors and
multicore processors are bringing high performance, tight integration and miniaturisation into the em-
bedded device market. The SoC technique implements a total system on a chip by integrating different
functionalities with a processor core on an integrated circuit. We will discuss about SoCs in a later chap-
ter. The fourth generation embedded systems are making use of high performance real time embedded
operating systems for their functioning. Smart phone devices, mobile internet devices (MIDs), etc. are
examples of fourth generation embedded systems.
1.4.1.S What Next? The processor and embedded market is highly dynamic and demanding. So
'what will be the next smart move in the ne:x;t embedded generation?' Let's wait and see.

1.4.2 Classification Based on Complexity and Performance

This classification is based on the complexity and system performance requirements. Accqrding to ~his
classification, embedded systems can be grouped into:
1.4.2.1 Small-Scale Embedded Systems Embedded systems which are simple in application
needs and where the performance requirements are :not time critical fall under this category. An elec-
tronic toy is a typical example of a small-scale embedded system. Small-scale embedded systems are
usually built around low performance and low cost 8 or 16 bit microprocessors/microcontrollers. A
small-scale embedded system may or may not contain an operating system for its functioning.
1.4.2.2 Medium-Scale Embedded Systems Embedded systems which are slightly complex
in hardware and firmware (software) requirements fall, under this category. Medium-scale emb'edded
systems are usually built around medium performance, low cost 16 or 32 bit microprocessors/microcon-:
trollers or digital signal processors. They usually contain an embedded operating system (either general_
purpose or real time operating system) for functioning.
1.4.2.3 Large-Scale Embedded Systems/Complex Systems Embedded systems which
involve highly complex hardware and firmware requirements fall under this category. They are em-
ployed in mission critical applications demanding high performance. Such systems are commonly built
around high performance 32 or 64 bit RISC processors/controllers or Reconfigurable System on Chip
(RSoC) or multi-core processors and programmable logic devices. They may contain multiple proces-
sors/controllers and co-units/hardware accelerators for offloading the processing requirements from the
main processor of the system. Decoding/encoding of media, cryptographic function implementation,
etc. are examples for processing requirements which can be implemented using a co-processor/hard-
ware accelerator. Complex embedded systems usually contain ai_1.igh perfonµance Real Time Operating
System (RTOS) for task scheduling, prioritization and management:-

We are living in a world where embedded systems play a vital role in our day-to-day life, starting from
home to the computer industry, where most of.the people find their job for a livelihood. Embedded
technology has acquired a new dimension from its first generation model, the Apollo guidance computer,
to the latest radio navigation system combined with in-car entertainment technology and the micropro-
cessor based "Smart" running· shoes launched by Adidas in April 2005. The application areas and the
products in the embedded domain are countless. A few of the important domains and products are listed
below:
 r
Introduction to Embedded Systems

1. Consumer electronics: Camcorders, cameras, etc.

2. Household appliances: Television, DVD players, washing machine, fridge, microwave oven, etc.
3. Home automation and security systems: Air·conditioners, sprinklers, intruder detection alarms,
closed circuit television cameras, fire alarms, etc.
4. Automotive industry: Anti-lock breaking systems (ABS), engine control, ignition systems,
automatic navigation systems, etc. .
5. Telecom: Cellular telephones, telephone ·switches, handset multimedia applications, etc.
6. Computer peripherals: Printers, scanners, fax machines, etc.
7. Computer networking systems: Network routers, switches, hubs, firewalls, etc.
8. Healthcare: Different kinds of scanners, EEG, ECG·machines etc.
9. Measurement & Instrumentation: Digital multi me~ers, digital CROs, logic analyzers PLC
systems, etc.
10. Banking & Retail: Automatic teller machines (ATM) and currency count~rs, point of sales (POS)
11. Card Readers: Barcode, smart card readers, hand held devices, etc.

As mentioned in the previous section, embedded systems are used in various domains like consumer
electronics, home automation, telecommunications, automotive in~ustry, healthcare, control & instru~
mentation, retail and banking applications, etc. Within the domain itself, according to the application
usage context, they may have different functionalities. Each embedded system is designed to serve ·the
purpose of any one or a combination of the following.tasks:
1. Data collection/Storage/Representation
2. Data communication
3. Data (signal) processing
4. Monitoring
5. Control
6. Application specific user interface

1. 6 .1 Data Collection/Storage/Repre.sentation
Embedded systems designed for the purpose of data collection performs acquisition of data from the
external world. Data collection is usually done for storage, analysis, manipula~ion and transmission.
The term "data" refers all kinds of information, viz. text, voice, image, video, electrical signals and any
other measurable quantities. Data can be either analog (continuous) or digital (discrete). Embedded sys-
tems with analog data capturing techniques collect data directly in the form of analog signals whereas
embedded systems with digital data collection mechanism converts the analog signal to corresponding
digital signal using analog to digital (AID) converters and then collects the binary equivalent of the
analog data. If the data is digital, it can be directly captured without any additional interface by digital
embedded systems.
The collected data may be stored directly in the system or may be transmitted to some other systems
or it may be processed by the system or it may be deleted instantly after giving a meaningful representa-
tion. These actions are purely dependent on the purpose for which the embedded system is designed.
Embedded systems designed for pure measurement applications without storage, used in control and
 Introduction to Embedded Systems

instrumentation domain, collects data and gives a meaningful representation of the collected data by
means of graphical representation or quantity value and deletes the collected data when new data arrives
at the data collection terminal. Analog and digital CROs without storage memory are typical examples
of this. Any measuring equipment used in the medical domain for monitoring without storage function-
ality also comes under this category.
Some embedded systems store the collected data for processing and analysis. Such systems incor-
porate a built-in/plug-in storage memory for storing the captured data. Some of them give the user a
meaningful representation of the collected data
by visual (graphical/quantitative) or audible
means using display units [Liquid Crystal Dis-
play (LCD), Light Emitting Diode (LED), etc.]
buzzers, alarms, etc. Examples are: measuring
instruments with storage memory and monitor-
ing instruments with storage memory used in
medical applications. Certain embedded systems
store the data and will not give a representation
of the same to the user, whereas the data is used
for internal processing.
A digital camera is a typical example of an
. embedded system with data collection/storage/
representation of data. Images are captured and ( Fig:,~l,i) ~A~}~i_ta} came~af~·r im~ge capturing/
s\<>t!lge/d~splay .
the captured image may be stored within the V :,c-:y~t,-t,_,;,/,-••J':.. ,•/ < '• '•
(Pho:to .courtesy of Casio-Model EXILIM ex-ZBSO
0
C •

memory of the camera. The captured image can (www:casio.com))

also be presented to the user through a graphic
LCD unit.

1.6.2 Data Communication

Embedded data communication systems are deployed in
applications ranging from complex satellite communi-
cation systems to simple home networking systems. As
mentioned earlier in this chapter, the data collected by an
embedded terminal may require transferring of the same
to some other system located remotely. The transmission
is achieved either by a wire-line medium or by a wire-
less medium. Wire-line medium was the most common
choice in all olden days embedded systems. As technolo-
gy is changing, wireless medium is becoming the de-facto
standard for data communication in embedded systems.
A wireless medium offers cheaper connectivity solutions
and make the communication link free from the hassle of
wire bundles. Data can eithe~ be transmitted by analog
means or by digital means. Modem industry trends are ( Fig.1.2) A wireless network router for data
settling towards,digital communication. communication
(Photo courtesy of Linksys
The data collecting embedded terminal itself can (www.Iinksys.com). A division of CISCO
incorporate d~ta communication units like wireless system)
 Introduction to Embedded Systems

mo9ules (Bluetooth, ZigBee, Wi-Fi, EDGE, GPRS, etc.) or wire-line modules (RS-232C, USB, TCP/IP,
PS2, etc.). Certain embedded systems act as a dedicated transmission unit between the sending and
receiving termiiµts, offering sophisticated functionalities like data packetizing, encrypting and decrypt-
ing. Network hubs, rputers, switches, etc. are typical examples of dedicated data transmission embedded
systems. They act as mediators in data communication and provide various features like data security,
monitoring etc.

1.6.3 Data (Signal) Processing

As mentioned earlier, the data (voice, image, video, elec-
trical signals and other measurable quantities) collected
by embedded systems may be used for various kinds of
data _processing. Embedded systems with signal process-
ing functionalities are employed in applications demand-
ing signal processing like speech coding, synthesis, audio
video codec, tral}smission applications, etc.
A digital hearing aid is a typical example of an embed-
ded system employing data processing. Digital hearing aid
improves the hearing capacity of hearing impaired persons.

1.6.4 Monitoring · Cffifi .3) ~

A~.~. ~.;·.J1.;,.'.!t.~11,1.e,~dp.·g aide. ~.P,.~. ~.·.·y.·.•.·.~l. ···~.~.·.·.g.·.··...· :·.•·•·.·.·.:.,·. '
s1gn:c1.l processing techn1g:u;e{l tt 1
Embedded systems falling under this category are spe- (Sietnens TRIANO 3 Digital hef;IIiii.g1aia;{:;; '
Siemens Audiology Copyright© 2.0¢$) £t,:,
cifically designed for monitoring purpose. Almost all ·,,:,"'"".,'];,;,,,

embedded products coming under the medical domain are

with monitoring functions only. They are used for determining the state of some variables using input
sensors. They cannot impose control over variables. A very good example is the electro cardiogram
(ECG) machine for monitoring the heartbeat of a patient. The machine is intended to do the monitoring
of the heartbeat. It cannot impose control over the
heartbeat. The sensors used in ECG are the different
electrodes connected to the patient's body.
Some other examples of embedded systems with
monitoring function are measuring instruments like
digital CRO, digital multimeters, logic analyzers,
etc. used.in Control & Instrumentation applications.
They are used for knowing (monitoring) the status
of some variables like current, voltage, etc. They
cannot control the variables in tum.

1.6.5 Contr9l
Embedded systems with control functionalities
impose control over some variables according to the ( Fig. J.4) A p~ttent wonitoring system for
moiilto1irig heartbeat
changes in input variables. A system with control (Phdti:i::oait~sy~(Philips Medical Systems
functionality contains both sensors and actuators. (www.medical.philiP,s.com/))
Sensors are connected to the input port for capturing
 Introduction to Embedded Systems

the changes in environmental variable or measuring variable. The actuators connected to the output port
are controlled according to the changes in input variable to put an impact on the controlling variable to
bring the controlled variable to the specified range.
Air conditioner system used in our home to control the room temperature to a specified limit is a typi-
cal example for embedded system for control purpose. An airconditioner pontains a room temperature-
sensing element (sensor) which may be a therm-
istor and a handheld unit for setting up (feeding)
the desired temperature. The handheld unit may
be connected to the central embedded unit resid-
ing inside the airconditioner through a wireless link
or through a wired link. The air compressor unit ESG21HRIA
acts as the actuator. The compressor is controlled
according to the current room temperature and the
desired temperature set by the end user.
Here the input variable is the current room tem-
perature and the contro1led variable is also the room
temperature. The controlling variable is cool air flow by the compressor unit. If the controlled variable
and input variable are not at the same value, the controlling variable tries to equalise them through
taking actions on the cool air flow.

1.6.6 Application Specific User Interface

These are embedded systems with application-specific user
interfaces like buttons, switches, keypad, lights, bells, display
units, etc. Mobile phone is an example for this. In mobile phone
the user interface is provided through the keypad, graphic LCD
J
:, module, system speaker, vibration alert, etc.

After three years of extensive research work, Adidas launched

the "Smart" running shoes in the market in April 2005. The term
"Smart Shoe" may sound gimmicky. But adaptive cushioning
provided by the shoe makes sense, ahd the design engineer-
ing behind the shoes is very impres•sive. The shoe constantly
adapts its shock-absorbing characteris~(s to custopiize its value;1
to the in~i vi dual runner: depending on the running style, pac~, (-Fi-.g-.'-1.~6) An en:fJi~tided syst~m with
body weight, and runnmg surface. The shoe. uses a magnetic an a.ppl~pation-specific user
sensing system to measure cushioning level, which is adjusted interfac"e
· d' · 1 · I · umt· that contro1s a motor- dnven
· (Photo courtesy of Nokia·
via a 1g1ta s1gna processmg Mobile Handsets (www.nokia.com))
cable system.
 Introduction to Embedded Systems

A hall effect sensor is positioned at the top of the "cushioning element", and the magnet is placed at
the bottom of the element. As the cushioning compresses on each impact, the sensor measures the dis-
tance from top to bottom of mid-sole (accurate to 0.1 mm). About 1000 readings per second are taken
and relayed to the shoe's microprocessor. The Microprocessor (MPU) is positioned under the arch of
the shoe. It runs an algorithm that compares the compression messages received from the sensor to a
preset range of proper cushioning levels, so it understands if the shoe is too soft or too firm. Then the
MPU sends a command to a micro motor, housed in the mid-foot. The micro motor turns a lead screw
to lengthen or shorten a cable secured to the walls of a plastic-cushioning element. When the cable is
shortened, the cushioning element is pulled taut and compresses very little. A longer cable allows for
a more cushioned feel. A replaceable 3-V battery powers the motor and lasts for about 100 hours of
runnmg.
The Portland, Ore-based Adidas Innovation Team that developed the shoe was led by Christian
DiBenedetto. It also included electromechanical engineer Mark Oleson, as well as a footwear developer
and two industrial designers. Oleson explains that the teatn chose a magnetic sensor because it could
measure the amount of compression in addition to the time it took to reach full compression. Gather-
ing sensor data, he says, meant little without building a comparative "running context". So one of the
first steps in developing the MPU algorithms was building this database. Runners wore test shoes that
gathered information about various compression levels during a run. Then the runners were interviewed
to learn their thoughts about the different cushion
levels. "When the two matched up, that helped
validate our sensor," says Oleson.
Adaptations in the cushioning element account
for the change of running surface and pace of the
runner, and they're made gradually over an aver-
age of four running steps. The goal is for the run-
ner not to feel any sudden changes. Adaptations
are made during the "swing" phase rather than the
"stance" phase of the stride (i.e. when the foot is
off the ground). If the shoe's owner prefers a more
cushioned or a firmer "ride," adjustments can be
made via "+" and " " buttons that also activate the
intelligent functions of the shoe.
LED indicators confirm when the electronics
are turned on (The lights do not remain on when
the shoes are in use). If the shoes aren't turned on,
they operate like old-fashioned "manual" running
shoes. The shoes tum off if their owner is either
inactive or at a walking pace for 10 minutes.
Source Electronic Design
www.electronicdesign.com/ Articles/Index. ( Fig. 1.7) Electronics-enabled "Smart" running
cfm?AD= 1&ArticleID= 10113 'shoe~d'rom'Adidas ·
Re-printed with permission (Photo. co11rt'esy ofAdidas - Salomon AG
(www.adidas.com))
 Introduction to Embedded Systems

Summary )
,.~,,,,.,.'

~.
✓ An etn?e~d,e,;i:l ~ystem is an Electronic/Electro~niechanicaFsystem ,designe1·to11etform a spe~ific ,fun:ctio~~t{

✓ Ap6Jlo G~iq~ceCpmputer (AOC) is the fus'trec9gnis'19,mg~%fu1rnl{~gq~Zf;ffs!~ ;

:~~~-~
gu~Mnge sofuprtter'.for 'the Minuteman~r missHt<''Y¥ thf;'fir~t!in&sfj:ii91~c~d \~m1i:~:
✓ ;~~~~q'.,p,n Jti~J9t11ple~ity. qnd. perfon;ru111ce requiremints,,' !efube4cl~d.'.:syste'mffmf C '
ine4!uffl!syale~ho)ilrg~~s9ale/corriple~.
,' ,·• •'.:; / ,,,,'.' ',, ( . '" ,', .
.. .,.. .!·•· • . . . ... '• ' ''. . ,,.\,
~
t ;,,;;/3,r:.i~\
.{; ·;•,-·-/:••,,,-,J;;,J,.,YJ~•• .·~fi::f;:. .;l;\
"•"·•ttr,;e;~;,,/;;-.f•"'\{l""i'

✓ Tlje Bfe~ence, o,f ~mbedded systems vary from.~u;11ple.electrp1,11f toy~ ,TQ,,9Rl\1.Ple?it:;:ff1-g)J~d.fi}1~~tl

syStftlirf::./ <f ' • .. . . ·• • .•. . . '.' •· · . . . ,·: 2 t., .;:: :;:\fr
j;~': :,":i!
✓ Emhe,ddid systems are designed to serve ihe p~rpose of any one or (~9rnbU1atfon offd~. '• ollec .. ;ii['
reprJ~eniation,\iata communication, data (signal) processing, monit~ririg, cbntrot16t ~~pli~atiori '~peci ~;;gs,~l;~
interfate. · ·. · · / , · · ·· · ;•.J~I!~¥r
~,_.K_e_yw-or_d_s__) .
' ,. . , ' ~· ' :,. . .,,,·· ' ' ' " ,:'!"'.:~ .•;.;•,':~,.·:,><,'.:~.~).::~
Embedded:srste~ : An electronic/electro~mechanical systell,1 which is designed to perform aspecificfµncti(jp,aiid./
. is a combination ()fb,o~ hard.ware anctfii,il\1/;re . · :','\. · , · · ·. . ,· · · · ·~./:Yt-Ji1f:
Microprq:cess6t . : A silicon chipseprysenting a_ Central Processing :Unit (CPU) , . . . , . ,, ,.. ,, //;~J\t.
' Micro~ohtrtiller ··: ,A highly. fote'grateg chip tha~ contain~. a. <:::tlJ, scr<1tchpq1:!,RAM, specia:l and gentral p\ ,,.,,, •ii
register~ays-~dfat~fft~d per~pherals ... ··.. ..•... . ? . : . ... _:_. -~,:., .,::.{: , .
,·:;:f\tt;'j,
DSP : Digital Signal Processor is a powerful special purpose 8/16/32 b1t~ic(9pro~essor des,:1$~2-.-'
specifically to rp.eet the cornputatiop.aLdemands fl!ld pay.er constraints , . . . . ·. '
I ASIC a
: Application Specific Integrated Cir~uit is niid~ochild~signed to p~rform a specific or uniqhe

I
application
Sens~r A transducer device that converts energy from-one form to another for any measurement or
control purpose
Actuator : A fonn of transducer device (mechanical or electrical) which converts signals to correspond-

I
ing physical action (motion)·
LED Light Emitting Diode. An ;:mtput device producing visual indication in the form of light in
accordance with current flow
Buzzer A piezo-electric device for generating audio indication. It contains a piezo-electric diaphragm
1 which produces audible sound in response to the voltage applied to it
I Operating system : A piece of software designed to manage and allocate system resources and execute other
pieces of software
Electro Cardiogram : An embedded device for heartbeat monitoring
(ECG)
SCADA : Supervisory Control and Data Acquisition System. A data acquisition system used in indus-
trial control applications
RAM : Random Access memory. Volatile memory
ADC Analog to Digital Converter. An integrated circuit which converts analog signals to digital
form
 Introduction to Embedded Systems

~.;~irreto~th . .
J~iifltr··· .·
-~ .", /2,.,., "'' '
j'~' //, ~ "L ·--.,

-Objective Questions
1. Embedded systems are
(a) General purpose (b) Special purpose
2. Embedded system is
(a) An electronic system . (b) A pure mechanical system
(c) An electro-mechanical system (d) (a) or (c)
3. Which of the following is not true about embedded systems?
(a) Built around specialised hardware (b) Always contain an operating system
(c) Execution behaviour may be detenninistic (d) All of these
(e) None of these
4. Which of the following is not an example of a 'Small-scale Embedded System'?
(a) Electronic Barbie doll (b) Simple calculator
(c) Cell phone (d) Electronic toy c~r
5. The first recognised modem embedded system is
(a) Apple Computer (b) Apollo Guidance Computer (AGC)
(c) Calculator (d) Radio Navigation System
6. The first mass produced embedded system is
(a) Minuteman-I (b) Minuteman-II
(c) Autonetics D-17 _(d) Apollo Guidance Computer (AGC)
7. Which of the following is (are) an intended purpose(s) of embedded systems?
(a) Data collection (b) Data processing (c) Data communication
(d) All of these (e) None of these
8. Which of the following is an (are) example(s) of embedded system for data communication?
(a) USB Mass storage device (b) Network router
(c) Digital camera (d) Music player
(e) All of these (f) None of these
9. A digital multi meter is an example of an embedded system for
(a) Data communication (b) Monitoring (c) Control (d) All of these
(e) None of these
10. Which of the.following is an (are) example(s) of an embedded system for signal processing?
(a) Apple iPOD (media player device) (b) SanDisk USB mass storage device
(c) Both (a) and (b) (d) None of these

Review Questions
1. What is an embedded system? Explain the different applications of embedded systems.
2. Explain the vario:us putposes of embedded systems in detail with illustrative examples.
3. Explain the differenf classifications of embedded systems. Give an example for each.
 V Learn the building bloc~pf a typical Embed<}ed System
.· Learn aboutGeneraf;i&«rpose Pcocessprs (GPPs) .· .. ,c:/vst(u~fi:JTJ5eCf!ro~~SJ6rS,(JfJfP{), J1icr~ptq- .
cessors, MJcrocohitollet{ Digital Signal Proc ' ' SO~,?;;Harvard'and, Vod,Nearndnn Rriotessd(
. Big:end10n vJs Uttle endian pra( , .
'learn about different PLDs like Complex' Progi~'fri
'ori an~ Instructiqn,~1pe,lir11hg ·: ">
tes (CPLDs), Field 'Programmable Gate, Arrays
(FPGAs), etc. , , ..• ,r,.tJ.t,'i,~;c},i!J;i::,i".,·· . ... ·.· . , . . . .: .......
Learn about thedifferent.memory tec;hryof951,ie~.qncJ rii~m{:·.. · JJ~ef[n,,?f!Jh,fpdeqsy~{~[E:'!f~v~J~T;(rlent 7r ·. 1
Leqrn about Masked RQM (MROM), PROM,. O[P, ER~OM, .~§EJ~ .. . qFLASH,. n1embry fot:~rrJ,b,fciq?,fftrmWa[eJJorgge
'·✓ leam about Seria[Access Memory (SAM), 'Stdtic-Rand6m'Ai::ces[Memdry (SRAM), Dynamk1~qr,dqmA.ccesso'.fr1~{iiB,y'
(DRAM) and No,nvolgtile SRAM {NI/RAM) . . ' ,, . ,,J '.- . · .r•: i;~\-)J,.~,~- ' "~·;,;~'
· ✓ Understand the 'aijJerent factors to be considered in the selection 0Trr1iiinoryfor embe~ded sysfems
.✓. Undwstand the role of sensor$; actuqJors ~dd thei(inteifacinfwliftbe,I/0 silbsYstems.o~an f0b({ddedsJifiN"I '
✓ learn about the intetfadng of LEDt l•segfu~~t tfiD DfsR{gys,/rifg, ~uize~ Stepper, ~otoi~'Relqys,Optbcq'cipieis,
Matrix keyboard, Push button switch~s, ProgrtJmifrable Periph?riil ifiterface Device ce4 ,8255 PPI}, etc. w.#h 'the
1/0 subsystem of the embedded system \
✓ Learn about the different communication inte,jaces of an embedded system
✓ Understand the various chip level communication inteif,aces like 12C, SP!, UART, 1-wire, parallel bus, etc.
✓ Understand the different wired and wireless external communication inte,jaces like RS-232C, RS-485, Parallel Port
USB, IEEE1394, Infrared (IrDA), Bluetooth, Wi-Fi, ZigBee, GPRS, etc.
✓ Know what embedded firmware is and its role in embedded systems
✓ Understand the different system components like keset Circuit, Brown-out protection circuit, Oscillator Unit, Real-
Time Clock (RT[) and Watchdog Timer unit
✓ Understand the role of PCB in embedded systems

A typical embedded system (Fig. 2.1) contains a single chip controller, which acts as the master brain
of the system. The controller can be a Microprocessor· (e.g. Intel 8085) or a microcontroller (e.g. Atmel
AT89C51) or a Field Programmable Gate Array (FPGA) device (e.g. Xilinx Spartan) or a Digital Signal
Processor (DSP) (e.g. Blackfin® Processors from Analog Devices) or an Application Specific Integrated
 Introduction to Embedded Systems

FPGA/ASIC/DSP/SoC
Microprocessor/controller Embedded
Firmware

Embedded System

Real World

Circuit (ASIC)/Application Specific Standard Product (ASSP) (e.g. ADE7760 Single Phase Energy
Metreing IC from) Analog Devices for energy metering applications).
Embedded hardware/software systems are basically designed to regulate a physical variable or to ma-
nipulate the state. of some devices by sending some control signals to the Actuators or devices connected
to the O/p ports of the system, in response to the input signals provided by the end users or Sensors
which are connected to the input ports. Hence an embedded system can be viewed as a reactive system.
The control is achieved by processing the information coming from the sensors and user interfaces, and
controlling some actuators that regulate the physical variable.
Key boards, push button switches, etc. are examples for common user interface input devices where-
as LEDs, liquid crystal displays, piezoelectric buzzers, etc. are examples for common user interface
output devices for a typical embedded system. It should be noted that it is not necessary that all embed-
ded systems should incorporate these I/O user interfaces. It solely depends on the type of the application
for which the embedded system is designed. For example, if the embedded system is designed for any
handheld application, such as a mobile handset application, then the system should contain user inter-
faces like a keyboard for performinginput operations and display unit for providing users the status of
various activities in progress.
Some embedded systems do not require any manual intervention for their operation. They automati-
cally sense the variations in the input parameters in accordance with the changes in the real world, to
which they are interacting through the _sensors which are connected to the input port of the systeff1:. The
r
I'
i
The Typical Embedded System

sensor information is passed to the processor after signal conditioning and digitisation. Upon receiving
the sensor data the processor or brain of the embedded system performs sol):le pre-defined operations
with the help of the firmware embedded in the system and sends some actuating signals to the actua-
tor connected to the output port of the embedded system, which in turn acts on the (?Ontrolling variable
to bring the controlled variable to the desired level to make the embedded system_ work in the desired
manner.
The Memory of the system is responsible for holding the control algorithm and other important con-
figuration details. For most of embedded systems, the memory for storing the algorithm or configuration
data is of fixed type, which is a kind of Read Only Memory (ROM) and it is not available for the end
user for modifications, which means the memory is protected from unwanted user interaction by impk:-
menting some kind of memory protection mechanism. The most common types of memories used
embedded systems for control algorithm storage are OTP, PROM, UVEPROM, EEPROM and FLASH.
Depending on the control application, the memory size may vary from a few bytes to megabytes. We
will discuss them in detail in the coming sections. Sometimes the system requires temporary memory
for performing arithmetic operations or control algorithm execution and this type of memory is known
as "working memory". Random Access Memory (RAM) is used in most of the systems as the working
.memory. Various types of RAM like SRAM, DRAM and NVRAM are used for this purpose. The size
of the RAM also varies from a few bytes to kilobytes or megabytes depending on the application. The
details given under the section "Memory" will give you a more detailed description of the working
memory.
An embedded system without a control algorithm implemented memory is just like a new born baby.
It is having all the peripherals but is not capable of malcing any decision depending on the situational as
well as real world changes. 1 only difference is that the memory of a new born baby is self-adaptive,
meaning that the baby will try to learn from the surroundings and from the mistakes oommitted. For
embedded systems it is the responsibility of the designer to impart intelligence to the system.
In a controller-based embedded system, the controller may contain internal memory for storing the
control algorithm and it may be an EEPROM or FLASH memory varying from a few kilobytes to mega-
bytes. Such controllers are called controllers with on-chip ROM, e.g. Atmel AT89C5 l. Some controllers
may not contain on-chip memory and they require an external (off-chip) memory for holding the contrcl
algorithm, e.g. Intel .803 lAH.

Embedded systems are domain and application specific and are built around a central core. The core of
the embedded system falls into any one of the following categories:
1. General Purpose and Domain Specific Processors
1.1 Microprocessors
1.2 Microcontrollers
1. 3 Digital Signal Processors
2. Application Specific Integrated Circuits (ASICs)
3. Programmable Logic Devices (PLDs)
4. Commercial off-the-shelf Components (COTS)
If you examine any embedded system you will find that it is built around any of the core units men-
tioned above.
 I'
Introduction to Embedded Systems

2 .1.1 General Purpose and Domain Spe.cific Processors

Almost 80% of the embedded systems are processor/controller based. The processor may be a micro-
processor or a microcontroller or a digital signal processor, depending on the domain and application.
Most of the embedded systems in the industrial control and monitoring applications make use of the
commonly available microprocessors or microcontrollers whereas domains which require signal
processing such as speech coding, speech recognition, etc. make use of special kind of digital signal
processors supplied by manufacturers like, Analog Devices, Texas Instruments, etc.
2.1.1.1 Microprocessors A Microprocessor is a silicon chip representing a central processing unit
(CPU), whi~h is capable of performing arithmetic as well as logical operations according to a pre-de.;
fined set of instructions, which is specific to the manufacturer. In general the CPU contains the Arith-
metic and Logic Unit (ALU), control unit and working registers. A microprocessor is a dependent unit
and it requires the combination of other hardware like memory, timer unit, and interrupt controller, etc.
for proper functioning. Intel claims the credit for developing the first microprocessor unit Intel 4004,
a 4bit processor which was released in November 1971. It featured lK data memory, a 12bit program
counter and 4K program memory, sixteen 4bit general purpose registers and 46 instructions. It ran at a
clock speed of 740 kHz. It was designed for olden day's calculators. In 1972, 14 more instructions were
added to the 4004 instruction set and the program space is upgraded to 8K. Also interrupt capabilities
were added to it and it is renamed as Intel 4040. It was quickly replaced in April 1972 by Intel 8008
which was similar to Intel 4040, the only difference was that its program counter was 14 bits wide and
the 8008 served as a terminal controller. In April 1974 Intel launched the first 8 bit processor, the Intel
8080, with 16bit address bus and program counter and sevep 8bit registers (A-E,H,L: BC, DE, and HL
pairs formed the 16bit register for this processor). Intel 8080 was the most commonly used processors
for industrial control and other embedded applications in the 1975s. Since the processor required other
hardware components as mentioned earlier for its proper functioning, the systems made out of it were
bulky and were lacking compactness.
Immediately after the release of Intel 8080, Motorola also entered the market with their processor,
Motorola 6800 with a different architecture and instruction set compared to 8080.
In 197 6 Intel came up with the upgraded version of 8080 - Intel 8085, with two newly added instruc-
tions, three interrupt pins and serial I/O. Clock generator and bus controller circuits were built-in and
the power supply part was modified to a single +5 V supply.
In July 1976 Zilog entered the microprocessor market with its Z80 processor as competitor to Intel.
Actually-it was designed by an ex-Intel designer, Frederico Faggin and it was an improved version of
Intel'~ 8080 proces'sor, maintaining the original 8080 architecture and instruction set with an 8bit data
bus dnd a 16bit address bus and v\'f8B capable of executing all instructions of 8080 .•It included 80 more
new instructions and it brought out the concept of register banking by doubling the register set. Z80 also
included two sets of index registers for flexible design.
Technical advances in the field of semiconductor industry brought a new dimension to the micro-
processor market and twenti~th century witnessed a fast growth in processor technology. 16, 32 and
1

64 bit processdrs came into the place of conventional 8bit processors. The initial 2 MHz clock is now
1

an old story. Today processors with clock speeds up to 2.4 GHz are availabl.e in the market. More and
more competitors entered into the processor market offering high speed, high performance and low cost
processors for customer design needs.
Intel, AMD, Freescale; IBM, TI, Cyrix, Hitachi, NEC, LSI Logic,' etc. are the key players in the
processor market. Intel still leads the market with cutting edge technologies in the processor industry.
 The Typical Embedded System

Different instruction set and system architecture are available for the design of a microprocessor.
Harvard and Von-Neumann are the two common system architectures for processor design. Processors
based· on Harvard architecture contains separate buses for program memory and data memory, whereas
processors based on Von-Neumann architecture shares a single system bus for program and data memo-
ry. We will discU_SS,-n'lore about these architectures later, under a separate topic. Reduced Instruction Set
Computing (RISC) and Complex Instruction Set Computing (CISC) are the two common Instruction
Set Architectures (ISA) available for processor design. We will discuss the same under· a separate topic
in this section..
2.1.1.2 Gen·eral Purpose Processor (GPP) vs. Application-Specific Instruction Set Processor
(ASIP) A General Purpose Processor or GPP is a processor designed for general computational tasks.
The processor running inside your laptop or desktop (Pentium 4/AMD Athlon, etc.) is a typical ex-
ample for general purpose proce~sor. They are produced in large volumes and targeting the general
market. Due to the high volume production, the per unit cost for a chip is low compared to ASIC or
other specific ICs. A typical general purpose processor contains an Arithmetic and Logic Unit (ALU)
and Control Unit (CU). On the other hand, Application Specific Instruction Set Processors (ASIPs)
are processors with architecture and instruction set optimised to specific-domain/application require-
ments like network processing, automotive, telecom, media applications, digital signal processing, con-
trol applications, etc. ASIPs fill the architectural spectrum between general purpose processors and
Application Specific Integrated Circuits (ASICs). The need for an ASIP arises when the traditional
general purp,ose processor are unable to meet the increasing application needs. Most of the embedded
systems are built around application specific instruction set processors. Some microcontrollers (like
automoti;ve AVR, USB AVR from Atmel), system on chips, digital signal processors, etc. are examples
for application specific instruction set processors (ASIPs). ASIPs incorporate a processor and on-chip
peripherals, demanded by the application requirement, program and data memory.
2.1.1.3 Microcontrollers AMicrocontroller is a highly integrated chip that contains a CPU, scratch
pad RAM, special and general purpose register arrays, on chip ROM/FLASH memory for program stor-
age, timer and interrupt control units and dedicated 1/0 ports. Microcontrollers can be considered as a
super set of microprocessors. Since a microcontroller contains all the necessary functional blocks for
independent working, they found greater place in the embedded domain in place of microprocessors.
Apart from this, they are cheap, cost effective and are readily available in the market.
Texas Instrument's TMS I 000 is considered as the world's first microcontroller. We cannot say it as a
fully functional microcontroller when we compare it with modem microcontrollers. TI followed Intel's
4004/4040, 4 bit processor design a_nd added some amount of RAM, program storage memory (ROM)
and 1/0 support on a single chip, there by eliminated the requirement of multiple hardware chips for
self-functioning. Provision to add custom instructions to the CPU was another innovative feature of
TMS 1000. TMS 1000 was released in 1974.
In 1977 Intel entered the microcontroller market with a family of contro,llers c,oming under one
umbrella named MCS-48™ family. The processors came under this family were IB038HL, 8039HL,
8040AHL, 8048H, 8049H and 8050AH. Intel 8048 is recognised as Intel's first miorocontroller and it
was the most proniinent member in the MCS-48™t family. It was used i~ the or,iginal I~M PC key-
board. The inspiration behind 8048 was Fairchild's F8 microprocessor and Inters goal of developing a
low cost and small size processor. The design of8048 adopted a true Harvardhrchite9fure where pro-
gram and data memory shared the same address bus and is differentiated by the i;,elajed control signals.
tMCS-48™ is a trade mark owned by Intel
 Introduction to Embedded Systems

Eventually Intel came out with its most fruitful design in the 8bit microcontroller domain-the 8051
family and its derivatives. It is the most popular and powerful 8bit microcontroller ever built. It was
developed in the 1980s and was put under the family MCS-51. Almost 75% of the microcontrollers
used in the embedded domain were 8051 family based controllers during the 1980-90s. 8051 proces-
sor cores are used in more than 100 devices by more than 20 independent manufacturers like Maxim,
Philips, Atmel, etc. under the license from Intel. Due to the low cost, wide availability, memory efficient
instruction set, mature developmenttools and Boolean processing (bit manipulation operation) capabil-
ity, 8051 family derivative microcontrollers are much used in high-volume consumer electronic devices,
entertainment industry and other gadgets where cost-cutting is essential.
Another important family of microcontro1lers used in industrial control and embedded applications is
the PIC family micro controllers from Micro~hip Technologies (It will be discussed in detail in a later
section of this book); It is a high performance RISC microcontroller complementing the CISC (complex
instruction set computing) features of 8051. The terms RISC and CISC will be explained in detail in a
separate heading. ·
Some embedded system applications require only 8bit controllers whereas some embedded applica-
tions requiring superior performance and computational needs demand 16132bit microcontrollers. Infi-
neon, Freescale, Philips, Atmel, Maxim, Microchip etc. are the key suppliers of 16bit microcontrollers.
Philips tried to extend the 8051 family microcontrollers to use for 16bit applications by developing the
Philips XA (eXtended Architecture) microcontroller series.
8bit microcontrollers are commonly used in embedded systems where the. processing power is not
a big constraint. As mentioned earlier, n::iore than 20 companies are producing different flavours of the
8051 family microcontroller. They try to add more and more functionalities like built in SPI, I2C serial
buses, USB controller, ADC, Networking capability, etc. So the competitive market is driving towards
a one-stop solution chip in microcontroller domain. High processing speed microcontroller families
like ARMl 1 series are also available in the market, which provides solution: to applications requiring
hardware acceleration and high processing capability.
Freescale, NEC, Zilog, Hitachi, Mitsubishi, Infineon, ST Micro Electronics, National, Texas Instru-
ments, Toshiba, Philips, Microchip, Analog Devices, Daewoo, Intel, Maxim, Sharp, Silicon Laborato-
ries, TDK, Triscend, Winbond, Atmel, etc. are the key players in the microcontroller market. Of these
Atmel has got special-significance. They are the manufacturers of a variety of Flash memory based
microcontrollers. They also provide In~System Programmability (which will be discussed in detail in a
later section of this book) for the controller. The Flash memory technique helps in fast reprogramming
of the chip and thereby reduces the product development time. Atmel also provides another special fam-
ily of mierocontroller called AVR (it will be discussed in detail in a later chapter), an 8bit RISC Flash
microcontroller, fast enough to execute powerful instructions in a single clock cycle and provide the
latitude you need to optimise power consumption.
The instruction set architecture of a microcontroller can be either RISC or CISC. Microcontrollers
are designed for either general purpose application requirement (general purpose controller) or domain-
specific application requirement (application specific instruction set processor). The Intel 8051 micro-
controller is a typical example for a general purpose microcontroller, whereas the automotive AVR
microcontroller family from Atmel Corporation is a typical example for ASIP specifically designed for
the automotive domain. ·
2.1.1.4 1i.1ic:-c.·p.roc·f'SSOr vs Microcontroller The following table summarises the differences
between a microcontrotier and microprocessor.
 The Typical Embedded System

-_~,-~:-:;_~-t~if~1~-:;; ~i--l·,7:c~~u,<;:_ i_: ',_; ,~-~~~ ,~1 :- ~ -~<, ..

;? ..._;\: _~-4';>•,.~<,,'--. ,,' ,, , ..,,, ,;. ..r:- ·,·.:: · .._ .." ,; i · • 1• , . ., ' • ·; ;--. ,•, . <:":··~-c.~,- ,. J _ "'/;·.:. :Ff,?;!'·:'< ·' ¢"' •

dt§i{tC.QA, .Ql\ip ,r~f~~enh11,g1a ~~IlJ!~bptoQfS,§iflg;, h !D1~I~:y9Ptfbll~J,lsI~;~ij~ggJy:c:intygrat~~ ,q4jpJhat

0

:,~if(<;t;P): '¥4¼~~ \S;Fflrt~!?li Qf n~t.fopntng'tr,jth-· ·tCQ11t~i~~~~z_QlIU; § ' .. ' '.:;:. :t!lA14,:;$p.~ci'lt:a;n4

f~frtig,1~S,;;te. .> ,~zj9fti(1~er~t.tonsaccording toa >~e11~r.:1t1p~,<;lS,~J'~g ,¥s;,<oll chipllQ1vf/
µry::Jlefinea' ' setfqf:t
-"'-·. '";_.,,,--,,~,,,:" •;:), 'i·t<
Qns F:L~SH,m~p.1,0_., ~rtn;n~r:a11d
"':/ _· ~"e:-.'.:··-'-,,; ,.

2.1.1. S Digital Signal Processors Digital Signal Processors (DSPs) are powerful special purpose
8/16/32 bit microprocessors designed specifically to meet the computational demands and power con-
straints of today's embedded audio, video, and communications applications. Digital signal processors
are 2 to 3 times faster than the general purpose microprocessors in signal processing applications. This
is because of the architectural difference between the two. DSPs implement algorithms in hardware
which speeds up the execution whereas general purpose processors implement the algorithm in finn-
ware and the speed of execution depends primarily on the clock for the processors. In general, DSP can
be viewed as a microchip designed for perfmming high speed computational operations for 'addition',
'subtraction', 'multiplication' and 'division'. A typical digital signal processor incorporates the follmv-
ing key units:
Program Memory Memory for storing the program required by DSP to process the data
Data Memory Working memory for storing temporary variables and data/signal to be processed.
Computational Engine Perfonns the signal processing in accordance with the stored program
memory. Computational Engine incorporates many specialised arithmetic units and each of them oper-
ates simultaneously to increase the execution speed. It also incorporates multiple hardware shifters for
shifting operands and thereby saves execution time.
I/0 Unit Acts as an interface between the outside world and DSP. It is responsible for capturing sig-
nals to be processed and delivering the processed signals.
 r
Introduction to Embedded Systems

Audio video signal processing, telecommunication and multimedia applications are typical examples
where DSP is employed. Digital signal processing employs a large amount of real-time calculations.
Sum of products (SOP) calculation, convolution, fast fourier transform (FFT), discrete fourier transform
(DFT), etc, are some of the operations performed by digital signal processors.
Blackfin®t processors from Analog Devices is an example of DSP which delivers breakthrough
signal-processing performance and power efficiency wfiile also offering a full 32-bit RlSC MCU pro-
gramming model. Black:fin processors present high-performance, homogeneous software targets, which
allows flexible resource allocation between hard real-.tiJne signal processing tasks and non real-time
control tasks. System control tasks can often run in the s!J.adow of demanding signal processing and
multimedia tasks.
2.1.1. 6 RISC vs. CISC Processors/Controllers The term RlSC stands for Reduced Instruction
Set Computing. As the name implies, all RlSC processors/controllers possess lesser number of instruc-
tions, typically in the range of 30 to 40. CISC stands for Complex Instruction Set Computing. From
the definition itself it is clear that the instruction set is complex and instructions are high in number.
From a programmers point of view RlSC processors are comfortable since s/he needs to learn only a
few instructions, whereas for a CISC processor s/he needs to learn more number of instructions and
should understand the context of usage of each instruction (This scenario is explained on the basis of
a programmer following Assembly Language coding. For a programmer following C coding it doesn't
matter since the cross-compiler is responsible for the conversion of the high level language instructions
to machine dependent code). Atmel AVR microcontroller is an example for a RlSC processor and its in-
struction set contains only 32 instructions. The original version of 8051 microcontroller (e.g. AT89C51)
is a CISC controller and its instruction set contains 255 instructions. Remember it is not the number of
instructions that determines whether a processor/controller is CISC or RlSC. There are some other fac-
tors like pipelining features, instruction set type, etc. for determining the RlSC/CISC criteria. Some of
the important criteria are listed below:

···-·· · ,,,:: _>f.1:''-' ·--:_~- ·: _·:,= ·"'-:;<•:_:··: '._. ,_~·::-' ._. "';'."::r~·_.""... _,._ ··;-~·-=:>:·, _< :·' _.. :'•':-_'/- ~
Orthogonal instruction: set :(Allows each iiistniction to N~nJofiji9gon.al 'it\~!fueti , ·. ..iY(A'.l\)i'.isf~ui;ti~nt·ar(p:ot
operate on any register ·a1,1d ·use lhy addressing mode). ~Hbwea ·to; operate pn'-<!1fregist¢r~d.gse. anr,)i<ldiessilig ..
rriode:lfls instrudiori~spJbH{c) . . . .. ii.. { .
~~ '. ,-"' - -~-' ,

riie
A large number of registers are available · Limited number of genexal P,vrpose, regist~ts.
Prograunnet)i~~4§; ~~4e'.t~j~~f~te . ~k; .jfi~iiiit[~" ;l

-si~~it~e.~~i¥i?~ lft~;!~tf i·''.:. ::/ J; ..

·r -,,·,a; ..\.'. .·;;;6i•,,-\.~-,\:;·..,.#/')__ · '.. ~ ~
,.:-.~.•=,.,:...
:~·~-:1 :.r·.t --·:_;1t;?i{"t.;t:~Lt1-,i~tr~~i~!~i\~~:}??·,. .<,
,;.~ ,yt~l ;: •:\~:::-r:~7•:": 7:~~.:;, ~(~}_ -,~->,
,·•. •·•·.••':...·~.•····
- .. _ -,_. _ ;. -· ·-

Single, fjxed length instrµctions

'.. -~Less.:1fiic6Ji'
·--y~J[?~~~-::; : ~~-,.: ·;- -
With Harvard.Architecture Can be Harvard or Von~Neum~·Architb'ctu~e
I hope now you are clear about the tenns RlSC and CISC in the processor technology. Isn't it? .
tB!ackfin® is a Registered trademark of Analog Devices Inc.
 The Typical Embedded System

2.1.1. 7 Harvard vs. Von-Neumann Processor/Controller Architecture The terms Harvard

and Von-Neumann refers to the processor architecture design.
Microprocessors/controllers based on the Von-Neumann architecture shares a single common bus
for fetching both instructions and data. Program instructions and data are stored in a common main
memory. Von-Neumann architecture based processors/controllers first fetch an instruction and then
fetch the data to support the instruction from code memory. The two separate fetches slows down the
controller's operation. Von-Neumann architecture is also referred as Princeton architecture, since it was
developed by the Princeton University.
Microprocessors/controllers based on the Harvard architecture will have separate data bus and in-
struction bus. This allows the data transfer and program fetching to occur simultaneously oh both buses.
With Harvard architecture, the data memory can be read and written while the program memory is·being
accessed. These separated data memory and code memory buses allow one instruction to execute while
the next instruction is fetched ("pre-fetching"). The pre-fetch theoretically allows much faster execution
than Von-Neumann architecture. Since some additional hardware logic is required for the generation of
control signals for this type of operation it adds silicon complexity to the system. Figure 2.2 explains the
Harvard and Von-Neumann architecture concept.

Single shared bus

( Fig. 2..2) Harvard vs Von-Neumann architecture

The following table highlights the differences between Harvard and Von-Neumann architecture.

\:• •t-: 0
'>>•
,.a:~i~Mfi~iii~Fi;:~~;i:~r.,•~,,·.
•'' •• ~ , ,., ', " ,,:\''. Y~~~"<'';,-q"'"-;c:::; ""::?-~~,,!~r;;::::/'~J't1f."1f/,'.~~!1o'.r(~~ -:-w~f!,','; ;,;_,,~,~--!-; <,, ''i0:,';;•1•""'''""'',,::-• ":'',"'' ;"'' •. '
I{~~;;~~~~~:
••. •

·3 / $ii:\gltsJ:tare~1>jjptoi:1nstt%~t:1oii'lind data fetching

, , ,... ,

Separate buses for instruction and data fetchirt( .,,\~ '

;~fpipil~~~5~?:~lg}ireiforll1ilic,b_;ea#l.
Comparatively high cost
;'!!~w~IB()rr_ali&rlJii~~tprR\,}~#i~. · . .:'.'.'t'.:t~LiL
Since data memory and program memory ~fe s~or~d· ·since '"data mem~ry -~nd program· memory are stored
physically in different loeations, no chances foraccidental physically' .iri 'the' same cnip, chances for aecidentaf
corruption of program memory corruptfon of program memory

2.1.1.8 Big-Endian vs. Little-Endian Processors/Controllers Endianness specifies the order

in which the data is stored in the memory by processor operations in a multi byte system (Processors
whose word size is greater than one byte). Suppose the word length is two byte then data can be stored
in memory in two different ways:
1. Higher order of data byte at the higher memory and lower order of data byte at location just below
the higher memory.
2. Lower order of data byte at the higher memory and higher order of data byte at location just below
the higher memory.

tself-modifying code is a code/instruction which modifies itself while execution.

 Introduction to Embedded Systems

Little-endian (Fig. 2.3) means the lower-order byte of the data is stored in memory at the lowest ad-
dress, and the higher-order byte at the highest address. (The little end comes first.) For example, a 4 byte
long integer Byte3 Byte2 Bytel ByteO will be stored in the memory as shown below:

Base Address+ 0 Byte-0 0x20000 (Base Address )

Base Address + 1 ' Byte 1 0x20001 (Base Address+ 1)

Base Address + 2 Byte 2 Ox20002 (Base Address + 2)

Base Address + 3 Byte 3 0x20003 (Base Address+ 3)

Big-endian (Fig. 2.4) means the higher-order byte of the data is stored in memory at the lowest address,
and the lower-order byte at the highest address. (The big end comes first.) For example, a 4 byte long
integer Byte3 Byte2 Bytel ByteO will be stored in the memory as followst:

Base Address + 0 Byte 3 0x20000 (Base Address )

Base Address+ 1 Byte 2- 0x20001 (Base Address + 1)

Base Address + 2 Byte 1 0x20002 (Base Address + 2)

Base Address + 3 Byte0 0x20003 (Base Address+ 3)

( Fig. 2.4) Big-Endian operation

2.1.1. 9 Load Store Operation and Instruction Pipelining As men_tioned earlier, the RISC pro-
cessor instruction set is orthogonal, meaning it operates on registers. The memory access related opera-
tions are performed by the special instructions load and store. If the operand is specified as memory
location, the content of it is loaded to a register using the load instruction. The instruction store stores
data from a specified register to a specified memory location. The concept of Load Store Architecture
,is illustrated with the following example:
Suppose x, y and z are memory locations and we want to add the contents of x and y and store the
result in location z. Under the load store architecture the same is achieved with 4 instructions as shown
in Fig. 2.5.
The first instruction load RI, x loads the register RI with the content of memory location x, the sec-
10:qd instruction load R2,y loads the register R2 with the content of memory location y. The instruction

t Note that the base address is chosen arbitrarily as 0x20000

 The Typical Embedded System

r------2--------
I
I .- 1
1 I I
I I I load Rl, x ----. G)
I I I load R2,y - - - 0)
1x
.. y 3 I add R3, Rl, R2 - G)
z I store R3, z - - - G)
I
i · .___ _~ II
l _ - - - - - .... - - -- - --4- - - - ....

add R3, RI, R2 adds the content of registers Rl and R2 and stores the result in register R3. The next
instruction store R3,z stores the content of register R3 in memory location z.
The conventional instruction execution by the prpcessor follows the fetch-decode-execute sequence.
Where the 'fetch' part fetches the instruction from program memory or code memory and the decode
part decodes the instruction to generate the necessary control signals. The execute stage reads the oper-
ands, perform ALU operations and stores the result. In conventional program execution, the fetch and
decode operations are performed in sequence. For simplicity let's consider decode and execution togeth-
er. During the decode operation the memory address bus is available and if it is possible to effectively
utilise it for an instruction fetch, the processing speed can be increased. In its simplest form instruction
pipelining refers to the overlapped execution of instructions. Under normal program execution flow it
is meaningful to fetch the next instruction to execute, while the decoding and execution of the current
instruction is in progress. If the current instruction in progress is a program control flow transfer instruc-
tion like jump or call instruction, there is no meaning in fetching the instruction following the current
instruction. In such cases the instruction fetched is flushed and a new instruction fetch is performed to
fetch the instruction. Whenever the current instruction is executing the program counter will be loaded
with the address of the next instruction. In case of jump or branch instruction, the new location is known
only after completion of the jump or branch instruction. Depending on the stages involved in an instruc-
tion (fetch, read register and decode, execute instruction, access an operand in data memory, write back
the result to register, etc.), there can be multiple levels of instruction pipelining. Figure 2.6 illustrates the
concept of Instruction pipelining for single stage pipelining.

~--flock pulses Clock pulses Clock pulses

! Machine cycle l Machine cycle 2 Machine cycle 3

F~tin (~C)
,_,- •' .,.~ff-' .'"

· Execute(PC 1) _
Execute (PC) Fetch.(PC+ 2)
,_,,;;;, _---- __ ' i ,,,,,_.;-~_ . ~ .. ;:, .. ·

PC : Program Counter

(Fig.is") The single-stage pipelining concept

 ,
Introduction to Embedded Systems

2.1.2 Application Specific Integrated Circuits (ASICs)

Application Specific Integrated Circuit (ASIC) is a microchip designed to perform a specific or unique
application. It is used as replacement to conventional general purpose logic chips. It integrates several
functions into a single chip and there by reduces the system development cost. Most of the ASICs are
proprietary products. As a single chip, ASIC consumes a very small area in the total system and thereby
helps in the design of smaller systems with high capabilities/functionalities.
ASICs can be pre-fabricated for a special applicatio_n or it can be custom fabricated by using the com-
ponents from a re-usable 'building block' library of components for a particular customer application.
ASIC based systems are profitable only for large volume commercial productions. Fabrication of ASICs
requires a non-refundable initial investment for the process technology and configuration expenses. This
investment is known as Non-Recurring Engineering Charge (NRE) and it is a one time investment.
If the Non-Recurring Engineering Charges (NRE) is borne by a third party and the Application
Specific Integrated Circuit (ASIC) is made openly available in the market, the ASIC is referred as
Application Specific Standard Product (ASSP). The ASSP is marketed to multiple customers just as a
general-purpose product is, but to a smaller number of customers since it is for a specific application.
"The ADE7760 Energy Metre ASIC developed by Analog Devices for Energy metreing applications is
a typical example for ASSP".
Since Application Specific Integrated Circuits (ASICs) are proprietary products, the developers of
such chips may not be interested in revealing the internal details of it and hence it is very difficult to
point out an example of it. Moreover it will create legal disputes if an illustration of such an ASIC prod-
uct is given without getting prior permission from the manufacturer of the ASIC. For the time being,
let us forget about it. We will come back to it in another-part of this book series (Namely, Designing
Advanced Embedded Systems).

2. I. 3 Programmable Logic Devices

Logic devices provide specific functions, including device-to-device interfacing, data communication,
signal processing, data display, timing and control operations, and almost every other function a system
must perform. Logic devices can be classified into two broad categories-fixed and programmable. As
the name indicates, the circuits in a fixed logic device are permanent, they perform one function or set
of functions-once manufactured, they cannot be changed. On the other hand, Programmable Logic
Devices (PLDs) offer customers a wide range of logic capacity, features, speed, and voltage characteris-
tics-and these devices can be re-configured to perform any number of functions at any time.
With programmable
1.
logic devices, designers use inexpensive software tools to quickly develop, sim-
ulate, and test their designs. Then, a,design can be quickly programmed into a device, and immediately
tested in a live circuit. The PLD that is used for this prototyping is the exact same PLD that will be used
in the final production of a piece of end equipment, such as a network router, a DSL modem, a DVD
player, or an automotive navigation system. There are no NRE costs and the final design is completed
much faster than that of a custom, fixed logic device. Another key benefit of using PLDs is that dur-
ing the design phase,customers can change the circuitry as often as they want until the design operates
to their satisfaction. That's because PLDs are based on re-writable memory technology-to change the
design, the device is simply reprogrammed. Once the design is final, customers can go into immediate
production by simply programming as many PLDs as they need with the final software design file.
2.1.3.1 CPLDs and FPGAs The two major types of programmable logic devices are Field Program-
mable Gate Arrays (FPGAs) and Complex Programmable Logic Devices (CPLDs). Of the two, FPGAs
·r
f

The Typical Embedded System

offer the highest amount of logic density, the most features, and the highest performance. The largest
FPGA now shipping, part of the Xilinx Virtex™t line of devices, provides eight million "system gates"
(the relative density of logic). These advanced devices also offer features such as built-in hardwired
processors (such as the IBM power PC), substantial amounts of memory, clock management systems,
and support for many of the latest, very fast device-to-device signaling technologies. FPGAs are used
in a wide variety of applications ranging from data processing and storage; to instrumentation, telecom-
munications, and digital signal processing.
CPLDs, by contrast, offer much smaller amounts oflogic-up to about 1O,OQO gates. But CPLDs offer
very predictable timing characteristics and are therefore ideal for critical control appljcations. CPLDs
such as the Xilinx CoolRunner™t series also require extremely low amounts of power and are very in-
expensive, making them ideal for cost-sensitive, battery-operated, portable applications such as mobile
phones and digital handheld assistants. ·
Advantages of PLD Programmable logic devices offer a number of important advantages over fixed
logic devices, including:
• PLDs offer customers much more flexibility during the design cycle because design iterations are
simply a matter of changing the programming file, and the results of design changes can be seen
immediately in working parts.
• PLDs do not require long lead times for prototypes or production parts-the PLDs are already on a
distributor's shelf and ready for shipment.
• PLDs do not require customers to pay for large NRE costs and purchase expensive mask sets-PLD
suppliers incur those costs when they design their programmable devices and are able to amortize
those costs over the multi-year lifespan of a given line of PLDs.
• PLDs allow customers to order just the number of parts they need, when they need them, allowing
them to control inventory. Customers who use fixed logic devices often end up with---€XCess inven-
tory which must be scrapped, or if demand for their product surges, they may be caught short of
parts and face production delays. ·
• PLDs can be reprogrammed even after a piece of equipment is shipped to a customer. In fact,
thanks to programmable logic devices, a number of equipment manufacturers now tout the ability
to add new features or upgrade products that already are in the field. To do this, they simply upload
a new programming file to the PLD, via the Internet, creating-new hardware logic in the system.
Over the last few years prog;rammable logic suppliers have made such phenomenal technical ad-
vances that PLDs are now seen as the logic solution of choice from many designers. One reason for
this is that PLD suppliers such as Xi~inx are "fabless" companies; instead of owning chip manufactur-
ing foundries, Xilinx outsource that job to partners like Toshiba and UMC, whose chief occupation is
making chips. This strategy allows Xilinx to focus on designing new product architectures, software
tools, and intellectual property cores while having access to the most advanced semiconductor process
technologies. Advanced process technologies help PLDs in a number of key areas: faster performance,
integration of more features, reduced power consumption, and lower cost.
FPGAs are especially popular for prototyping ASIC designs where the designer can test his design by
downloading the design file into an FPGA device. Once the design is set, hardwired chips are produced
for faster performance.
Just a few years ago, for example, the largest FPGA was measured in tens of thousands of system
gates and operated at 40 MHz. Older FPGAs also were relatively expensive, costing often more than
$150 for the most advanced parts at the time. Today, however, FPGAs with advanced features offer

t VirtexTM and CooIRunnerTM are the registered trademarks of Xilinx Inc.

 Introduction to Embedded Systems

millions of gates of logic capacity, operate at 300 MHz, can cost less than $10, and offer a new level of
integrated functions such as processors and memory.

2 .1.4 Commercial Off-the-Shelf Components (COTS)

A Commercial Off-the-Shelf (COTS) product is one which is used' as-is'. COTS products are designed
in such a way to provide easy integration and interoperability with existing system components. The
COTS component itself may be developed around a general purpose or domain specific processor or
an Application Specific Integrated circuit or a programmable logic device. Typical examples of COTS .
hardware unit are remote controlled toy car control units including the RF circuitry part, high perfor-
mance, high frequency microwave electronics (2-200 GHz), high bandwidth analog-to-digital convert-
ers, devices and components for operation at very high temperatures, electro-optic IR imaging arrays,
UV/IR detectors, etc. The major advantage of using COTS is that they are readily available in the
market, are cheap and a developer can cut down his/her development time to a great extent. This in turn
reduces the time to market your embedded systems.
The TCP/IP plug-in module available from various
manufactures like 'WIZnet', 'Freescale', 'Dynalog', etc.
are very good examples of COTS product (Fig. 2. 7). This
network plug-in module gives the TCP/IP connectivity to
the system you are developing. There is no need to design
this module yourself and write the firmware for the TCP/
IP protocol and data transfer. Everything will be read-
ily supplied by the COTS manufacturer. What you need
to do is identify the COTS for your system and give the
plug-in option on your board according to the hardware
plug-in connections given in the specifications of the (Fi9.~.1).,,2
ni \
,f , ..•

COTS. Though multiple vendors supply COTS for the IT ,'' ... ' nef:
'(WI,?net.N!ViiOJ o)i¥1ug in:M,oc/µJei!Coiitte~y
same application, the major problem faced by the end- of W!Znet htip:tlwww:wiznet.co.kr/enl) ·
user is that there are no operational and manufacturing
standards. A Commercial off-the-shelf (COTS) component manufactured by a vendor need not have
hardware plug-in and firmware interface compatibility with one manufactured by a second.:v-endor for
the same application. This restricts the end-user to stick to a pa1iicular vendor for a particular ·coTS.
This greatly affects the product design.
The major drawback of using COTS components in embedded design is that the manufacturer of the
COTS component may withdraw the product or discontinue the production of.the COTS at any time if
a rapid change in technology occurs, and this will adversely affect a commercial manufacturer of the
embedded system which makes use of the specific COTS product.

. 2.2. MEMORY
Memory is an important part of a processor/controller based embedded systems. Some of the proces-
sors/controllers contain built in memory and this memory is referred as on-chip memory. Others do
not contain any memory inside the chip and requires external memory to be connected with the control-
ler/processor to store the control algorithm. It is called off-chip memory. Also some working memory
is required for hoiding data temporarily during certain operations. This section deals with the different
types of memory used in embedded system applications.
 The Typical Embedded System

2.2.1 Program Storage Memory (ROM)

The program memory or code storage memory of an embedded system stores the program instructions
and it can be classified into different types as per the block diagram representation given in Fig. 2.8.

· ~
I

FLASH Code memory NVRAM

(ROM)

PROM Masked ROM EPROM EEPROM

(OTP) (MROM)

tfig'.'&:a) Classification of~rog~~Memory (ROM)

The code memory retains its contents even after the power to it is: turned off. It is generally known as
non-volatile storage memory. Depending on the fabrication, erasing and programming techniques they
are classified into the following types.
2.2.1.1 Masked ROM (MROM) Masked ROM is a one-time programmable device. Masked ROM
, makes use of the hardwired technology for storing data. The device is factory programmed by masking
and metallisation process at the time of production itself, according to the data provided by the end user.
The primary ·advantage of this is low cost for high volume production. They are the least expensive type
of solid state memory. Different mechanisms are used for the masking process of the ROM, like
1. Creation of an enhancement or depletion mode transistor through channel implant.
2. By creating the memory cell either using a standard transistor or a high threshold transistor. In the
high threshold mode, the supply voltage required to turn ON the transistor is above the normal
ROM IC operating voltage. This ensures that the transistor is always off and the memory cell
stores always logic 0.
Masked ROM is a good candidate for storing the embedded firmware for low cost embedded devices.
Once the design is proven and the firmware requirements are tested and frozen, the binary data (The
firmware cross compiled/assembled to. target processor specific machine code) corresponding to it can
be given to the MROM fabricator. The limitation with MROM based firmware storage is the inability to
modify the device finnware against firmware upgrades. Since the MROM is permanent in bit storage, it
is not possible to alter the bit information. ·
2.2.1.2 Programmable Read Only Memory (PROM) I (OTP) Unlike Masked ROM Memory,
One Time Programmable Memory (OTP) or PROM is not pre-programmed by the manufacturer. The
end user is responsible for programming these devices. This memory has nichrome or polysilicon wires
arranged in a matrix. These wires can be functionally viewed as fuses. It is programmed by a PROM
programmer which selectively burns the fuses according to the bit pattern to be stored. Fuses which are
not blown/burned represents a logic "1" whereas fuses which are blown/burned represents a logic "O".
The default state is logic "l". OTP is widely used for commercial production of embedded systems
whose proto-typed versions are proven and the code is finalised. It is a low cost solution for commercial
production. OTPs cannot be reprogrammed.
 Introduction to Embedded Systems

2.2.1.3 Erasable Programmable Read Only Memory (EPROM) OTPs are not useful and
worth for development purpose. During the development phase the code is subject to continuous chang-
es and using an OTP each time to load the code is not economical. Erasable Programmable Read Only
Memory (EPROM) gives the flexibility to re-program the same chip. EPROM stores the bit information
by charging the floating gate of an FET. Bit information is stored by using an EPROM programmer,
which applies high voltage to charge the floating gate. EPROM contains a quartz crystal window for
erasing the stored information. If the. window is exposed to ultraviolet rays for a fixed duration, the
entire memory will be erased. Even though the EPROM chip is flexible in terms of re-programmability,
it needs to be taken out of the c!rcuit boar~ and put in a UV eraser device for 20 to 30 minutes. So it is
a tedious and time-consuming process.
2.2.1.4 Electrically Erasable Programmable Read Only Memory (EEPROM) As the name
indicates, the information contained in the EEPROM memory can be altered by using electrical signals
at the register/Byte level. They can be erased and reprogrammed in-circuit. These chips include a chip
erase mode and in this mode they can be erased in a few milliseconds. It provides greater flexibility for
system design. The only limitation is their capacity is limited when compared with the standard ROM
(A few kilobytes).
2.2.1.5 FLASH FLASH is the latest ROM technology and is the most popular ROM technology used
in today's embedded designs. FLASH memory is a variation of EEPROM technology. It combines the
re-programmability of EEPROM and the high capacity of standard ROMs. FLASH memory is organ-
ised as sectors (blocks) or pages. FLASH memory stores information in an array of floating gate MOS-
FET transistors. The erasing of memory can be done at sector level or page level without affecting the
other sectors or pages. Each sector/page should be erased before re-programming. The typical erasable
capacity of FLASH is 1000 cycles. W27C512 from WINBOND (www.winbond.com) is an example of
64KB FLASH memory.
2.2.1.6 NVRAM Non-volatile RAM is a random access memory with battery backup. It contains
static RAM based memory and a minute battery for providing supply to the memory in the absence of
external power supply. The memory and battery are packed together in a single package. The life span
of NVRAM is expected to be around 10 years. DS1644 from Maxim/Dallas is an example of 32KB
NVRAM.

2.2.2 Read-Write Memory/Random Access Memory (RAM)

RAM is the data memory or working memory of the controller/processor. C0nlroller/processor can
read f~om it and write to it. RAM is volatile, meaning when the power is turned off, all the contents
are destroyed. RAM is a direct access memory, meaning we can access the desired memory location
directly without the need for traversing through the entire memory locations to reach the desired
memory position (i.e. random access of memory location). This is in contrast to the Sequential Access
Memory (SAM), where the desired memory location is accessed by either traversing through the entire
memory or through a 'seek' method. Magnetic tapes, CD ROMs, etc. are examples of sequential access
memories. RAM generally falls into three categories: Static RAM (SRAM), dynamic RAM (DRAM)
and non-volatile RAM (NVRAM) (Fig. 2.9).
2.2.2.1 Static RAM (SRAM) Static RAM stores data in the form of voltage. They are made up of
flip-flops. Static RAM is the fastest form of RAM available. In typical implementation, an SRAM cell
(bit) is realised using six transistors (or 6 MOSFETs). Four of the transistors are used for building the
l
The Typical Embedded System

Read/Write
Memory (RAM)

SRAM DRAM NVRAM

latch (flip-flop) part of the memory cell and two for controlling the access. SRAM is fast in operation
due to its resistive networking and switching capabilities. In its simplest representation an SRAM cell
can be visualised as shown in Fig. 2.10:

Bit Line B\ Bit Line B

Ql Q3

Q2 Q4
Vee

Word Line

(F:ig.2.10) SHAM cell imple~entation

This implementation in its simpler fonn can be Write control Read control
visualised as two-cross coupled inverters with read/
write control through transistors. The four transis-
tors in the middle fonn the cross-coupled inverters. Data to Data
This can be visualised as shown in Fig. 2.11. write read
From the SRAM implementation diagram, it is
clear that access .to the memory cell is controlled
by the line Word Line, which controls the access
transistors (MOSFETs) Q5 and Q6. The access tran- (Fig. 2.11) Visualisation of S1:ll,M cell
f sistors control the connection to bit lines B & B\. In
1 order to write a value to the memory cell, apply the desired value to the bit control lines (For writing 1,
"., make B 1 and B\ =O; For writing 0, make B Oand B\ =l) and assert the Word Line (Make Word line
 Introduction to Embedded Systems

high). This operation latches the bit written in the flip-flop. For reading the content of the memory cell,
assert both B and B\ bit lines to 1 and set the Word line to I.
The major limitations of SRAM are low capacity and high cost. Since a minimum of six transistors
are required to build a single memory cell, imagine how many memory cells we can fabricate on a sili-
con wafer.
2.2.2.2 Dynamic RAM(DRAM) DynamicRAMstoresdata Bit line B
in the form of charge. They are made up of MOS transistor
gates. The advantages of DRAM are its high density and low
cost compared to SRAM. The disadvantage is that since the
information is stored as charge it gets leaked off with time and Word line
to prevent this they need to be refreshed periodically. Special
circuits called DRAM controllers are used for the refreshing
operation. The refresh operation is done periodically in milli-
seconds interval. Figure 2.12 illustrates the typical implementa-
tion of a DRAM cell.
The MOSFET acts as the gate for the incoming and outgo-
-r
+

(Fig.'2.12) DRAM celliril.plementation

ing data whereas the capacitor acts as the bit storage unit. Table
given below summarises the relative merits and demerits of
SRAM and DRAM technology.

2.2.2.3 NVRAM Non-volatilf RAM is a random access memory with battery backup. It contains
static RAM based memory and a minute battery for providing supply to the memory in the absence
of external power supply. The memory and battery are packed together in a single package. NVRAM
is used for the non-volatile storage ofresults of operations or for setting up of flags, etc. The life span
of NVRAM is \expected to be around 10 years. DS 1744 from MaximJDallas is an example for 32KB
NVRAM.

2.2.3 Memory According to the Type of Interface

The interface (connection) of memory with the processor/controller can be of various types. It may be
a parallel interface [The parallel data lines (D0-D7) for an 8 bit processor/controller will be connected
to D0-D7 of the memory] or the interface may be a serial interface like I2C (Pronounced as I Square C.
It is a 2 line serial interface) or it may be an SPI (Serial peripheral interface, 2+n line interface where
n stands for the total number of SPI bus devices in the system). It can also be of a single wire intercon-
nection (like Dallas I-Wire ip.terface ). Serial interface is commonly used for data storage memory like
EEPROM. The memory density of a serial memory is usually expressed .in terms of kilobits, whereas
 The Typical Embedded System

that of a parallel interface memory is expressed in terms of kilobytes. Atmel Corporations AT24C512
is an example for serial memory with capacity 512 kilobits and 2-wire interface. Please refer to the
section 'Communication Interface' for more details on I2C, SPI and I-Wire Bus.

2.2.4 Memory Shadowing

Generally the execution of a program or a configuration from a Read Only Memory (ROM) is very slow
(120 to 200 ns) compared to the execution from a random access memory (40 to 70 ns). From the tim-
ing parameters it is obvious that RAM access is about three tirries as fast ·as ROM access. Shadowing
of memory is a technique adopted to solve the execution speed problem in processor-based systems.
In comkuter systems and video systems there will be a configuration holding ROM called Basic Input
Output Configuration ROM or simply BIOS. In personal computer systems BIOS stores the hardware
configuration information like the address assigned for various serial ports and other non-plug 'n' play
devices, etc. Usually it is read and the system is configured according to it during system boot up and
it is time consuming. Now the manufactures included a RAM behind the logical layer of BIOS at its
same address as a shadow to the BIOS and the first step that happens during the boot up is copying the
BIOS to the shadowed RAM and write protecting the RAM then disabling the BIOS reading. You may
be thinking that what a stupid idea it is and why both RAM and ROM are needed for holding the same
data. The answer is: RAM is volatile and it cannot hold the configuration data which is copied from the
BIOS when the power supply is switched off. Only a ROM can ho.Id it permanently. But for high system
performance it should be accessed from a RAM instead of accessing from a ROM.

2.2.5 Memory Selection for Embedded Systems

Embedded systems require a program memory for holding the control algorithm(For a super-loop based
design) or embedded OS and the applications designed to run on top of it (for OS based designs), data
memory for holding variables and temporary data during task execution, and memory for holding non-
volatile data (like configuration data, look up table etc) which are modifiable by the application (Unlike
program memory, which is non-volatile as well unalterable by the end user). The memory requirement
for an embedded system in terms of RAM and ROM (EEPROM/FLASH/NVRAM) is solely dependent
on the type of the embedded system and the applications for which it is designed. There is no hard and
fast rule for calculating the memory requirements. Lot of factors need to be considered when selecting
the type and size of memory for embedded system. For example, if the embedded system is designed
using SoC or a microcontroller with on-chip RAM and ROM (FLASH/EEPROM), depending on the ap-
plication need the on-chip memory may be sufficient for designing the total system. As a rule of thumb,
identify your system requirement and based on the type of processor (SoC or microcontroller with on-
chip memory) used for the design, take a decision on whether the on-chip memory is sufficient or exter-
nal memory is required. Let's consider a simple electronic toy design as an example. As the complexity
of requirements are less and data memory requirement are minimal, we can think of a microcontroller
with a few bytes of internal RAM, a few bytes or kilobytes (depending on the number of tasks and the
complexity of tasks) of FLASH memory and a few bytes of EEPROM (if required) for designing the
system. flence there is no need for external memory at all. A PIC microcontroller device which satisfies
the I/0 and memory requirements can be used in this case. If the embedded design is based on an RTOS,
the RTOS requires certain amount of RAM for its exe~ution and ROM for storing the RTOS image
(Image is the common na:ip.e giveµ for the binary data generated by the compilation of all RTOS source
files). Normally the binary cqde for RTOS kernel containing all the services is stored in a non-volatile
memory (Like FLASH) _as either compressed or non-compressed data. During boot-up of the device,
 Introduction to Embedded Systems

the RTOS files are copied from the program storage memory, decompressed if required and then loaded
to the RAM' for execution. The supplier of the RTOS usually gives a rough estimate on the run time
RAM requirements and program memory requirements for the RTOS. On top of this add the RAM
requirements for executing user tasks and ROM for storing user applications. On a safer side, always
add a buffer value to the total estimated RAM and ROM size requirements. A smart phone device with
Windows mobile operating system is a typical example for embedded device with OS. Say 64MB RAM
and 128MB ROM are the minimum requirements for running the Windows mobile device, ind~ed you
need extra RAM and ROM for running user applications. So while building the system, count the
memory for that also and arrive at a value which is always at the safer side, so that you won't end up in
a situation where you don't have sufficient memory to install and run user applications. There are two
parameters for representing a memory. The first one is the size of the memory chip (Memory density
express~d in terms of number of memory bytes per chip). There is no option to get a memory chip with
the exact required number of bytes. Memory chips come in standard sizes like 512bytes, 1024bytes
(1 kilobyte), 2048bytes (2 kilobytes), 4Kb,t 8Kb, 16Kb, 32Kb, 64Kb, 128Kb, 256Kb, 512Kb, 1024Kb
(1 megabytes), etc. Suppose your embedded application requires only 750 bytes of RAM, you don't
have the option of getting a memory chip with size 750 bytes, the only option left with is to choose
the memory chip with a size closer to the size needed. Here 1024 bytes is the least possible option. We
cannot go for 512 bytes, because the minimum requirement is 750 bytes. While you select a memory
size, always keep in mind the address range supported by your processor. For example, for a processor/
controller with 16 bit address bus, the maximum number of memory locations that can be addressed is
216 = 65536 bytes= 64Kb. Hence it is 'meaningless to select a 128Kb memory chip for a processor with
16bit wide address bus. Also, the entire memory range supported by the processor/controller may not
be available to the memory chip alone. It may be shared ~etween I/O, other !Cs and memory. Suppose
the address bus is 16bit wide and only the lower 32Kb address range is· assigned to the memory chip,
the memory size maximum required is 32Kb only. It is not worth to use a memory chip with size 64Kb
in such a situation. The second parameter that needs to be considered in selecting a memory is the word
size of the memory. The word size refers to the number of memory bits that can be read/write together
at a time. 4, 8, 12, 16, 24, 32, etc. are the word sizes supported by memory chips. Ensure that the word
size supported by the memory chip matches with the data bus width of the processor/controller.
FLASH memory is the popular choice for ROM (program storage memory) in embedded applica-
tions. It is a powerful and cost-effective solid-state storage technology for mobile electronics devices
and other consumer applications. FLASH memory comes in two major variants, namely, NAND and·
NOR FLASH. NAND FLASH is a high-density low cost non-volatile storage memory: On the other
hand, NOR FLASH is less dense and slightly expensive. But it supports the Execute in Place (XIP)
technique for program execution. The XIP technology allows the execution of code memory from ROM
itself without the need for copying it to the RAM as in the case of conventional execution method. It is
a good practice to use a combination of NOR and NAND memory for"storage memory requirements,
where NAND can be used for storing the program code and or data like the data captured in a camera
device. NAND FLASH doesn't support XIP and ifNAND FLASH is used for storing program code, a
DRAM can be used for copying and executing the program code. NOR FLASH supports XIP and it can
be used as the memory for bootloader or for even storing the complete program code.
The EEPROM data storage memory is available as either serial interface or parallel interface chip. If
the processor/controller of the device supports serial interface and the amount of data to write and read
to and from the device is less, it is better to have a serial EEPRQM.chip. The serial EEPROM saves the
address space of the total system. The memory capacity of the serial EEPROM is usµally expressed in
tKb-Kilobytes
 The Typical Embedded System

bits or kilobits. 512 bits, lKbits, 2Kbits, 4Kbits, etc. are examples for serial EEPROM memory repre-
sentation. For embedded systems with low power'requirements like portable devices, choose low power
memory devices. Certain embedded devices may be targeted for operating at extreme environmental
1l·
.,.t conditions like high temperature, high humid area, etc. Select an industrial grade memory chip in place
l of the conu:nercial grade chip for such devices.

At the very beginning of this chapter it is already mentioned that an embedded system is in constant
interaction with the Real world and the controlling/monitoring functions executed by the embedded
system is achieved in accordance with the changes happening to the Real world. The changes in sys-
tem environment or variables are detected by the sensors connected to the input port of the embedded
system. If the embedded system is designed for any controlling purpose, the system will produce some
changes in the controlling variable to bring the controlled variable to the desired value. It is achieved
through an actuator connected to the output port of the embedded system. If the embedded system is
designed for monitoring purpose only, then there is no need for including an actuator in the system. For
example, take the case of an ECG machine. It is designed to monitor the heart beat status of a patient
and it cannot impose a control over the patient's heart beat and its order. The sensors used here are the
different electrode sets connected to the body of the patient. The variations are captured and presented
to the user (may be a doctor) through a visual display or some printed chart.

2.3.1 Sensors
A sensor_is a transducer device that converts energy from one form to another for any measurement or
control purpose. This is what I "by-hearted" during my engineering degree from the transducers paper.
If we look back to the "Smart" running shoe example given at the end of Chapter 1, we can identify
that the sensor which measures the distance between the cushion and magnet in the smart running shoe
is a magnetic hall effect sensor (Please refer back).

2.3.2 Actuators
Actuator is a form of transducer device (mechanical or electrical) which converts signals to correspond-
ing physical action (motion) .. Actuator acts as an output device.
Looking back to the "Smart" running shoe example given at the end of Chapter 1, we can see that the
actuator used for adjusting the position of the cushioning element is a micro stepper motor (Please refer
back).

2.3.3 The I/0 Subsystem

The l/O subsystem of the embedded system facilitates the interaction of the embedded system with the
external world. As mentioned earlier the interaction happens through the sensors and actuators connect-
ed to the input and output ports respectively of the embedded system. The sensors may not be directly
interfaced to the input ports, instead they may be interfaced through signal conditioning and translating
systems like ADC, optocouplers, etc. This section illustrates some ofthe sensors and actuators .used in
embedded systems a~d the I/O systems to facilitate the interaction of embedded systems with external
world. '
 Introduction to Embedded Systems

2.3.3.1 Light Emitting Diode (LED) Light Emitting Diode (LED) is an important output device
for visual indication in any embedded system. LED can be used as an indicator for the status of various
signals or situations. Typical examples are indicating the presence of power conditions like 'Device
ON', 'Battery low' or 'Charging of battery' for a battery operated handheld
embedded devices.
Light Emitting Diode is a p-n junction diode (Refer Analog Electron-
ics fundamentals to refresh your memory for p-n junction diode ©) and it ~
contains an anode and a cathode. For proper functioning of the LED, the
anode of it should be connected to +ve terminal of the supply voltage and
cathode to the -ve terminal of supply voltage. The current flowing through
the LED must be limited to a value below the maximum current that it can
conduct. A resister is used in series between the power supply and the LED GND
to limit the current through the LED. The ideal LED interfacing circuit is (F~~-~-l~) ,~~p;,tiit~~~~~~f
shown in Fig. 2.13. ·
LEDs can be interfaced to the port pin of a processor/controller in two ways. In the first method, the
anode is directly connected to the port pin and the port pin drives the LED. In this approach the port pin
'sources' current to the LED when the port pin is at logic High (Logic '1 '). In the second method, the
cathode of the LED is connected to the port pin of the processor/controller and the anode to the sup-
ply voltage through a current limiting resistor. The LED is turned on when the port pin is at logic Low
(Logic 'O'). Here the port pin 'sinks' current. If the LED is directly connected to the port pin, depending
on the maximum current that a port pin can source, the brightness of LED may not be to the required
level. In the second approach, the current is directly sourced by the power supply and the port pin acts
as the sink for current. Here we will get the required brightness for the LED.
2.3.3.2 7-Segment LED Display The 7-segment
LED display is an output device for displaying alpha A
numeric characters. It contains 8 light-emitting diode
(LED) segments arranged in a special form. Out of the 8
LED segments, 7 are used for displaying alpha numeric
characters and· 1 is used for representing 'decimal point'
in decimal number display. Figure 2.14 explains the ar-
rangement of LED segments in (,I. 7-segment LED display.
The LED segments are named A to G and the· deci-
mal point LED segment is named as DP. The LED seg-
ments A to G and DP should be lit accordingly to display
D
DP •
numbers and characters. For example, for displaying the
number 4, the segments F, G, B and C are lit. For dis- §~ii~ 7~Segment LED Display
playing 3, the segments A, B, C, D, G and DP are lit. For
displaying the character 'd', the segments B, C, D, E and G are lit. All these 8 LED segments need to
be connected to one port of the processor/controller for displaying alpha numeric digits. The 7-segment
LED displays are available in two different configurations, namely; Comrrion Anode and Common
Cathode. In the common anode configuration, the anodes of the 8 segments are connected commonly
whereas in the common cathode configuration; the 8 LED segments share a common cathode line.
Figure 2.15 illustrates the Common Anode and Cathode configurations.
Based on the configuration of the 7-segment LED unit, the LED segment's anode or cathode is con- 1
nected to the port of the processor/controller in the order' A' segment to the least significant port pin•and
DP segment to the most significant port pin. ·
 The Typical ~mbedded System

Anode
DP G F E D C B A

DP G F E D C B A
Common Anode LED Display Cathode
Common Cathode LED Display

The current flow through each of the LED segments should be limited to the maximum value sup-
ported by the LED display unit. The typical value for the current falls within the range of 20mA. The
current through each segment can be limited by connecting a current limiting resistor to the anode or
cathode of each segment. The value for the current limiting resistors can be calculated using the current
value from the electrical parameter listing of the LED display.
For common cathode configurations, the anode of each LED segment is connected to the port pins of
the port to which the display is interfaced. The anode of the common anode LED display is connected to
the 5V supply voltage through a current limiting resistor and the catho& of each LED segment is con-
nected to the respective port pin lines. For an LED segment to lit in the Common anode LED configura-
tion, the port pin to which the cathode of the LED segment is
connected should be set at logic 0.
7-segment LED display is a popular choice for low cost
embedded applications like, Public telephone call monitorip.g I/0 interface
devices, point of sale terminals, etc. ___ I/0 interface
2.3.3.3 Optocoupler Optocoupler is a solid state device
to isolate two parts of a circuit. Optocoupler combines an LED
and a photo-transistor in a single housing (package). Figure
2.16 illustrates the functioning of an optocoupler device.
In electronic circuits, an optocoupler is used for suppressing interference in data communication,
circuit isolation, high voltage separation, simultaneous separation and signal intensification, etc.
Optocouplers can be used in either input circuits or in output circuits. Figure 2.17 illustrates the usage
Vee

1/p interface

Optocoupler
ICMCT2M
 Introduction to Embedded Systems

of optocoupler in input circuit and output circuit of an embedded system with a microcontroller as the
system core.
Optocoupler is available as ICs from different semiconductor manufacturers. The MCT2M IC from
Fairchild semiconductor (http://www.fairchildsemi.com1) is an example for optocoupler IC.
2.3.3.4 Stepper Motor A stepper motor is an electro-mechanical device which generates discrete
displacement (motion) in response. to de electrical signals. It differs from the normal de motor in its
operation. The de motor produces continuous rotation on applying de voltage whereas a stepper motor
produces discrete rotation in response to the de voltage applied to it. Stepper motors are widely used in
industrial embedded applications, consumer electronic products and robotics control systems. The paper
feed mechanism of a printer/fax makes use of stepper motors for its functioning.
Based on the coil winding arrangements, a two-phase stepper motor is classified into two. They are:
1. Unipolar
2. Bipolar
1. Unipolar A unipolar stepper motor contains two windings per
phase. The direction of rotation (clockwise or anticlockwise) of a
stepper motor is controlled by changing the direction of current
flow. Current in one direction flows through one coil and in the op-
posite direction flows through the o,ther coil. It is easy to shift the
direction of rotation by just switching the terminals to which the
coils are connected. Figure 2.18 illustrates the working of a two- GND
phase unipolar stepper motor.
The coils are represented as A, B, C and D. Coils A an_d C carry
current in opposite directions for phase I (only one of them will be
carrying current at a time). Similarly, B and. D carry current in opposite directions for phase 2 (only one
of them will be carrying current at a time).
Z. Bipolar A bipolar stepper motor contains single winding per phase. For reversing the motor rota-
tion the current flow through the windings is reversed dynamically. It requires complex circuitry for
current flow reversal. The stator winding details for a two phase unipolar stepper motor is shown in
Fig. 2.19.
The stepping of stepper motor can be implemented in different ways by changing the sequence of ac-
tivation of the stator windings. The different stepping modes supported by stepper motor are explained
below.
Full Step. In the full step mode both the phases are energised simultaneously. The coils A, B, C and D
are energised in the following order:

~tep
1

It should be noted that out of the two windings, only one winding of a phase is energised at a time.
 The Typical Embedded System

A C B D

.GND

GND

Wave Step In the wave step mode only one phase is energised at a time and each coils of the phase is
energised alternatively. The coils A, B, C and D are energised in the following order:

Half Step It uses the combination of wave and full step. It has the highest torque and stability. The
coil energising sequence for half step is given below.
 Introduction to Embedded Systems

The rotation of the stepper motor can be reversed by reversing the order in which the coil is
energised.
1\vo-phase unipolar stepper motors are the popular choice for embedded applications. The current
requirement for stepper motor is little high and hence the port pins of a microcontroller/processor may·
not be able to drive the1:1! directly. Also the supply voltage required to operate stepper motor varies
normally in the range 5V ~o 24 V. Depending on the current and voltage requirements, special drivjng
circuits are required to in~erface the step~er m~tor with microcontroller/proce~sors. ~ommercial off-
the-shelf stepper motor driver ICs are available m the market and they can be directly interfaced to the
microcontroller port. ULN2803 is an octal peripheral driver array available from ON semiconductors
and ST microelectronics for driving a 5V stepper motor. Simple driving circuit can also be built using
transistors.
The following circuit.diagram (Fig. 2.20) illustrates the interfacing of a stepper motor through a
driver circuit connected to the port pins of a microcontroller/processor.

B D

Vee

2.3.3.S Relay Relay is an electro-mechanical device. In embedded application, the 'Relay' unit acts
as dynamic path selectors for signals and power. The 'Relay' unit contains a relay coil made up of in-
sulated wire on a metal core and a metal armature with one or more contacts. .
'Relay' works on electromagnetic principle. When a voltage is applied to the relay coil, current flows
through the coil, which in tum generates a magnetic field. The magnetic field attracts the armature core
and moves the contact point. The movement of the contact point changes the power/signal flow path.
'Relays' are available in different configurations. Figure 2.21 given below illustrates the widely used
relay configurations for embedded applications.

Single pole single Single pole single

l
Single pole double
throw normally throw normally throw
open closed

( Fig. 2.21) Relay configurations

 The Typical Embedded System

The Single Pole Single Throw configuration has only one path for information flow. The path is
either open or closed in normal condition. For normally Open Single Pole Single Throw relay, the cir-
cuit is normally open and it becomes closed when the relay is energised. For normally closed Single
Pole Single Throw configuration, the circuit is normally closed and it becomes open when the relay is
energised. For Single Pole Double Throw Relay, there are two paths for information flow and they are
• selected by energising or de-energising the relay.
The Relay is normally controlled using a relay driver circuit connected to the port pin of the proces-
sor/controller. A transistor is used for building the relay driver circuit. Figure 2.22 illustrates the same.

Vee

Port pin

Relay unit

A free-wheeling diode is used for free-wheeling the voltage produced in the opposite direction
when the relay coil is de-energised. The freewheeling diode is essential for protecting the relay and the
transistor. .
Most of the industrial relays are bulky and requires high voltage to operate. Special relays called
'Reed' relays are available for embedded application requiring switching oflow voltage DC signals.
2.3.3.6' Piezo Buzzer Piezo buzzer is a piezoelectric device for generating audio indications in em-
bedded application. A piezoelectric buzzer contains a piezoelectric diaphragm which produces audible
sound in response to the voltage applied to it. Piezoelectric buzzers are available in two types. 'Self-
driving' and 'External driving'. Th_e 'Self-driving' circuit contains all the necessary components to gen-
erate sound at a predefined tone. It will generate a tone on applying the voltage. External driving piezo
buzzers supports the generation of different tones. The tone can be varied by applying a variable pulse
train to the piezoelectric buzzer. A piezo buzzer can be directly interfaced to the port pin of the proces-
sor/control. Depending on the driving current requirements, the piezo buzzer can· also be interfaced
using a transistor based driver circuit as in the case of a 'Relay'.
2.3.3. 7 Push Button Switch It is an input device. Push button switch comes in two coongurations,
namely 'Push to Make' and 'Push to Break'. In the 'Push to Make' configuration, the switch is normally
in the open state and it makes a circuit contact when it is pushed or pressed. In the 'Push to Break' con-
figuration, the switch is normally in the closed state and it breaks the circuit contact when it is pushed
or pressed. The push button stays in the 'closed' (For Push to Make type) or 'open' (For Push to Break
type) state as long as it is kept in the pushed state and it breaks/makes the circuit connection when it
 r
,,
I
I

Introduction to Embedded Systems

is released. Push button is used for generating a mo- Vee Vee

mentary pulse. In embedded application push button
is generally used as reset and start switch and pulse
generator. The Push button is normally connected to
the port pin of the host processor/controller. Depend- Port pin Port pin
ing on the way in which the push button interfaced to
the controller, it can generate either a 'HIGH' pulse or
a 'LOW' pulse. Figure 2.23 ~llustrates ?OW the push
button can be used for generating 'LOW' and 'HIGH'
pulses. ·
2.3.3.8 Keyboard Keyboard is an input device 'LOW' Pulse generator 'HIGH' Pulse generator
for user interfacing. If the number of keys required 1 Push button switch configura_tions
Fig. 2.231
is very limited, push button switches-can be used and (.
'thyy can be directly interfaced to the port pins for
reading. However, there may be situations demanding a large number of keys for user inp)lt (e.g. PDA
device with alpha-numeric keypad for user data entry). In such situations it may not be possible to inter-
face each keys to a port pin due to the limitation in the number of general purpose port pins available for
the processor/controller in use and moreover it is wastage of port pins. Matrix keyboard is an optimum
solution for handling large key requirements. It greatly reduces the number of interface connections. For
example, for interfacing 16 keys, in the direct interfacing technique 16 port pins cire required, whereas in
the matrix keyboard only 8 lines are required. The 16 keys are arranged in a 4 column x 4 Row matrix.
Figure 2.24 illustrates the connection of keys in a matrix keyboard.
In a matrix keybo<ird, the.keys are arranged in matrix fashion (i.e. they are connected in a row and
column style). For detecting a key press,the keyboard uses the scanning technique, where each row of
the matrix is pulled low and the columns are read. After reading the status of each columns correspond-
ing to a row, the row is pulled high and the next row is pulled low and the status of the columns are read.
This process is repeated until the scanning for all rows are completed. When a row is pulled low and if
a key connected to the row is pressed, reading the column to which the key is connected will give logic
0. Since keys are mechanical devices, there is a possibility for de-bounce issues, which may give mul-
tiple key press effect.for a single key press. To prevent this, a proper key de-bouncing technique should
be applied. Hardware key de-bouncer circuits and software key de-bounce techniques are the key de-
bouncing techniques available. The software key de-bouncing technique doesn't require any additional
hardware and is easy to implement. In the software de-bouncing technique, on detecting a key-press,
the key is read again after a de-bounce delay. If the key press _is a genuine one, the state of the key will
remain as 'pressed' on the second read also. Pull-up resistors are connected to the column lines to limit
the current that flows to the Row line on a key press.
2.3.3.9 Programmable Peripheral Interface (PPI) Programmable Peripheral Interface (PPI)
devices are used for extending the I/O capabilities of process?rs/controllers. Most of the processors/
controllers provide very limited number ofl/O and data ports and at tiin~s it may require more number
of I/O ports than the one supported by the controller/processor. A. programmable peripheral interface
device expands the I/O capabilities of the processor/controller. 825 5A is a popular PPI device for 8bit
processors/controllers. 8255A supports 24 I/O pii;is and these I/0:pins can be grouped as either three
8-bit parallel ports (Port A, Port Band Port C) or two 8bit parallel ports (Port A and Port B) with Port C
in any one of the following configurations:
 The Typical Embe,dded System

Vee

~ ~
r--- r---
-.::t= ~

RowO

Row l

Row2

Row3
y
0 ..... N (')

~ § § §
-u
;:I
0
.E!
u
0
.E!
0
u
-u
;:l
0

To microcontroller /processor port

1. As 8 individual I/O pins

2. Two 4bit ports namely Port CUPPER (Cu) and Port CLOWER (CL)
This is configured by manipulating the control register of 8255A. The control register holds the con-
figuration for Port A, Port B and Port C. The bit details of control register is given below:
D2 ))1 DO
The table given below explains the meaning and use of each bit.
 Introduction to Embedded Systems

Mode selector fcfal19 -· · · · nd ortB ,,,,,

D2 = O; Mode OAil? Port C lower,functioii$t~s·~·,·
02=1·Moae;
' :};;."\ its of.Port,.C~shindsh~:;
, , · , "'" ",i,;/.<·•i,'r,.,k''"<:··~

Please refer ro the 8255A datasheet available at http://www.intersil.com/data/fn/fn2969.pdf for more

details about the different operating modes of 8255.
Figure 2.25 illustrates the generic interfacing of a 8255A device with an 8bit processor/controller
with 16bit address bus (Lower order Address bus is multiplexed with data bus).

Data bus DO ... .D7

..----....,A0Pin9 .·•
1-------1 A1iuiJ
Po~
A2 ....A7 . .. .. PB7
Port
Address bus · Acldress ·
CS\ Pin 6
(A8 .... Al5) d~J~d~1 ... PC7

RD\.1----------------1RD\ Pin 5
)¼R_\ . WR\ Pi~ 36
RESETbUT RESET Pin 35

( Fig. 2.25) Interfacing of 8255 with an 8 bit microcontroller

The ports of 8255 can be configured for different modes of operation by the processor/controller.
 The Typical Embedded System

Communication interface is essential for communicating with various subsystems of the embedded
system and with the external world. For an embedded product, the communication interface can be
viewed in two different perspectives; namely; Device/board level communication interface (Onboard
Communication Interface) and Product level communication interface (External Communication Inter-
face). Embedded product is a combination of different types of components (chips/devices) arrangecl en
a printed circuit board (PCB). The communication channel which interconnects the various componenU;
within an embedded product is referred as device/board level communication interface (onboard com-
munication interface). Serial interfaces like I2C, SPI, UART, 1-Wire, etc and parallel bus interface> ?1
"

examples of 'Onboard Communication Interface'.

Some embedded systems are self-contained units and they don't require any interaction and data
transfer with other sub-systems or external world. On the other hand, certain embedded systems may
a part of a large distributed system and they require interaction and data tr~nsfer between various devic-
es and sub-modules. The 'Product level communication interface' (External Communication Interface)
is responsible for data transfer between the embedded system and other devices or modules. The exter-
nal communication interface can be either a wired media or a wireless media and it can be a serial or a.
parallel interface. Infrared (IR), Bluetooth (BT), Wireless LAN (Wi-Fi), Radio Frequency waves (RF),
GPRS, etc. are examples for wireless communication interface. RS-232C/RS-422/RS-485, USB, Eth-
ernet IEEE 1394 port, Parallel port, CF-II interface, SDIO, PCMCIA, etc. are examples for wired inter--
faces. It is not mandatory that an embedded system should contain an ~xternal communication interface.
Mobile communication equipment is an example for embedded system with external communication
interface.
The following section gives you an overview of the various 'Onboard' -and 'External' communica-
tion interfaces for an embedded product. We will discuss about the various physical interface, firmware
requirements and initialisation and communication sequence for these interfaces in a dedicated book
titled 'Device Interfacing', which is planned under this series.

2.4.1 Onboard Communication Interfaces

Onboard Communication Interface refers to the different communication channels/buses for interc011 -
necting the various integrated circuits and other peripherals within the embedded system. The following
section gives an overview of the various interfaces for onboard communication.
2.4.1.1 Inter Integrated Circuit (I2C) Bus The Inter Integrated Circuit Bus (I2C-Pronounccd
'I square C') is a synchronous bi-directional half duplex (one-directional communication at a given
point of time) two wire serial interface bus. The concept of I2C bus was developed by 'Philips semi-
conductors' in the early 1980s. The original intention ofI2C was to provide an easy way of connection
between a microprocessor/microcontroller system and the peripheral chips in television sets. The I2C
bus comprise of two bus lines, namely; Serial Clock-SCL and Serial Data-SDA. SCL line is respon-
sible for generating synchronisation clock pulses and SDA is responsible for transmitting the serial data
across devices. I2C bus is a shared bus system to which many_ number of I2C devices can be connected.
Devices connected to the I2C bus can act as either 'Master' device or 'Slave' device. The 'Master'
device is responsible for controlling the communication by initiating/terminating data transfer,·sending
data and generating necessary synchronisation clock pulses. 'Slave' devices wait for the commands
 \
Introduction to Embedded Systems

from the master and respond upon receiving the commands. 'Master' and 'Slave' devices can act as
either transmitter or receiver. Regardless whether a master is acting as transmitter or receiver, the syn-
chronisation clock signal is generated by the 'Master' device only. I2C supports multi masters on the
same bus. The following bus interface diagram shown in Fig. 2.26 illustrates the connection of master
and slave devices on the I2C bus.

SCL SDA Vee

2.2K

SDA
2.2K
SCL

SCL
SDA

SCL
SDA

y
I2Cbus

The I2C bus interface is built around an input buffer and an open drain or collector transistor. When
the bus is in the idle state, the open drainYcollector transistor will be in the floating state and the output
lines (SDA and SCL) switch to the 'High Impedance' state. For proper operation of the bus, both the bus
lines should be pulled to the supply voltage (+5V for TTL family and +3JV for CMOS family devices)
using pull-up resistors. The typical value of resistors used' in pull-up is 2.2K. With pull-up resistors, the
output )ines of the bus in the idle state will be 'HIGH'. .
The address of a I2C device is assigned by hardwiring the address lines of the· device to the desired
logic level. The address to various I2C devices in an embedded device is assi~ed and hardwired at the
time of designing the embedded hardware. The sequence of operations for con{municating with an I2C
slave device is listed below:
1. The master device pulls the clock line (SCL) of the bus to 'HIGH'
2. The master device pulls the data line (SDA) 'LOW', when the SCL line is at logic 'HIGH' (This
is the 'Start' condition for data transfer)
3. The master device sends the address (7 bit or 10 bit wide) of the 'slave' device to which it wants
to communicate, over the SD A line. Clock pulses are generated at the SCL line for synchronising
the bit reception by the slave device. The MSB ·Of the data is always transmitted first. The data in
the bus is valid during the 'HIGH' period of the clock signal
 The Typical Embedded System .

4, The master device sends the Read or Write bit (Bit value = 1 Read operation; Bit value 0 Write
operation) according to the requirement
5. The master device waits for the acknowledgement bit from the slave device whose address is sent
on the bus along with the Read/Write operation command. Slave devices connected to the bus
compares the address received with the address assigned to them
6. The slave device with the address requested by the master device responds by sending an ac-
knowledge bit (Bit value 1) over the SDA line
7. Upon receiving the acknowledge bit, the Master device sends the 8bit data to the slave device over
SDA line, if the requested operation is 'Write to device'. If the requested operation is 'Read from
device', the slave device sends data to the master over the SDA line
8. The master device waits for the acknowledgement bit from the device upon byte transfer compl0Le
for a write operation and sends an acknowledge bit to the Slave device for a read operation
9. The master devi_ce terminates the transfer by pulling the SDA line 'HIGH' when the clock line
SCL is at logic 'HIGH' (Indicating the 'STOP' condition)
I2C bus supports three different data rates. They are: Standard mode (Data rate up to 100kbits/sec
(100 kbps)), Fast mode (Data rate up to 400kbits/sec (400 kbps)) and High speed mode (Data rate up to
3.4Mbits/sec (3.4 Mbps)). The first generation I2C devices were designed to support data rates only up
to 100kbps. The new generation I2C devices are designed to operate at data rates up to 3.4Mbits/sec.
2.4.1.2 Serial Peripheral Inter[ace (SP/) Bus The Serial Peripheral Interface Bus (SPI) is a ~yn-
chronous bi-directional full duplex four-wire serial interface bus. The concept of SPI was introduced by
Motorola. SPI is a single master multf-slave·system. It is possible to have a system where more than one
SPI device can be master, provided the condition only _one master device is active at any given point of
l
time, is satisfied. SPI requires four signal lines for communication. They are:
Master Out Slave In (MOSI): Signal line carrying the data from master to slave device. It is
also known as Slave Input/Slave Data In (SI/SDI)
Master In Slave Out (MISO): Signal line carrying the data from slave to master device. It is
also known as Slave Output (SO/SDO)
Serial Clock (SCLK): Signal line carrying the clock signals
Slave Select (SS): Signal line for slave device select. It is an active low signal
The bus interface diagram shown in Fig. 2.27 illustrates the connection of master and slave devices
on the SPI bus.
The master device is responsible for generating the clock signal. It selects the required slave device
by asserting the c01Tesponding slave device's slave select signal 'LOW'. The data out line (MISO) of all
the slave devices when not selected floats at high impedance state.
The serial data transmission through SPI bus is fully configurable. SPI devices contain a certain set
of registers for holding these configurations. The serial peripheral control register holds the various con-
figuration parameters like master/slave selection for the device, baudrate selection for communication,
clock signal control, etc. The status register holds the status of various conditions for transmission and
reception.
SPI works on the principle of' Shift Register'. The master and slave devices contain a special shift
register for the data to transmit or receive. The size of the shift register is device dependent. Normally
it is a multiple of 8. Duribg transmission from the master to slave, the data in the master's shift register
is shifted out to the MOSI pin and it enters the shift register of the slave device through the MOSI pin
of the slave device. At the same time the shifted out data bit from the slave device's shift register enters
 Introduction to Embedded Systems

MOSl SCL MISO

MOSI
SCL
MISO
SS\

MOSI
scv
MISO
SS\

SPI bus

the shift register of the master device through MISO pin. In summary, the shift registers of 'master' and
'slave' devices form a circular buffer. For some devices, the decision on whether the LS/MS bit of data
needs to be sent out first is configurable through configuration register (e.g. LSBF bit of the SPI control
register for Motorola's 68HC12 controller). ··
When compared to I2C, SPI bus is most suitable for applications requiring transfer of data in 'streams'.
The only limitation is SPI doesn't support an acknowledgement mechanism.
2.4.1.3 Universal Asynchronous Receiver Transmitter (UART) Universal Asynchronous Re-
ceiver Transmitter (UART) based data transmission is an asynchronous form of serial data transmission.
UART based serial data transmission doesn't require a clock signal to synchronise the transmitting end
arid receiving end for transmission. Instead it relies upon the pre-defined agreement between the trans-
mitting device and receiving device. The serial communication settings (Baudrate, number of bits per
byte, parity, number of start bits and stop bit and flow control) for both transmitter and receiver should
be set as identical. The start and stop of communication is indicated through inserting special bits in the
data stream. While sending a byte of data, a start bit is added first and a stop bit is added at the end of
the bit stream. The least significant bit of the data byte follows the 'start' bit.
The 'start' bit informs the receiver that a data byte is about to arrive. The receiver device starts polling
its 'receive line' as per the baudrate settings. If the baudrate is 'x' bits per second, the time slot available
for one bit is 1/x seconds. The receiver unit polls the receiver line at exactly half of the time slot avail-
able for the bit. If parity is enabled for communication, the UART of the transmitting device adds a par-
ity bit (bit value is 1 for odd number of ls in the transmitted bit stream and Ofor even number of 1s). The
UART of the receiving device calculates the parity of the bits received and compares it with the received
parity bit for error checking; The UART of the receiving device discards the 'Start', 'Stop' and 'Parity'
 The Typical Embedded System

bit from the received bit stream and converts

the received serial bit data to a word (In the
case of 8 bits/byte, the byte is formed with the
received 8 bits with the first received bit as the
LSB and last received data bit as MSB).
For proper communication, the 'Transmit
line' of the sending device should be con-
nected to the 'Receive line' of the receiving
device. Figure 2.28 illustrates the same.
In addition to the serial data transmission TXD: Transmitter line
function, UART provides hardware handshak- RXD: Receiver line
ing signal support for controlling the serial (. ., 0•,,. ,LJ, ,;• ·,,;;,. ,.·:,,.,·.,· ,." ...
:Fig·/2,28 tUA.RT,:ln t:lrt·g··
data flow. UART chips are available from dif- >•y , • ✓: ,,·;,m i:,,d·. •'.., ··.··
ferent semiconductor manufacturers. National
Semiconductor's 8250 UART chip is considered as the standard setting UART. It was used in the origi-
nal IBM PC.
Nowadays most of the microprocessors/controllers are available with integrated UART functionality
and they provide built-in instruction supp9rt for serial data transmission and reception.
2.4.1.4 1-Wire Interface 1-wire interface is an asynchronous half-duplex communication protocol
developed by Maxim Dallas Semiconductor (http://www.maxim-ic.com). It is also known as Dallas
1-Wire® protocol. It makes use of only a single signal line (wire) called DQ for communication and
follows the master-slave communication model. One of the key feature of 1-wire bus is that it allows
power to be sent along the signal wire as well. The· l 2C slave devices incorporate internal capacitor
(typically of the order of 800 pF) to power the device from the signal line. The I-wire interface supports
a single master and one or more slave devices on the bus. The bus interface diagram shown in Fig. 2.29
illustrates the connection of master and slave devices on the I-wire bus.
Vee

4.7K

I
i
I
l

(~g. ~.29) 1-:Wire In~etface bus

 Introduction to Embedded Systems
r
f

Every I-wire device contains a globally unique 64bit identification number stored within it. This
unique identification number can be used for addressing individual devices present on the bus in case
there are multiple slave devices connected to the 1-wire bus. The identifier has three parts: an 8bit family
code, a 48bit serial number and an 8bit CRC computed from the first 56 bits. The sequence of operation
for communicating with a 1-wire slave device is listed below.
1. The master device sends a 'Reset' pulse on the 1-wire bus.
2. The slave device(s) present on the bus respond with a 'Presence' pulse.
3. The master device sends a ROM command (Net Address Command followed by the 64bit address
of the device). This addresses the slave device(s) to which it wants to initiate a communication.
4. The master device sends a read/write function command to read/write the internal memory or
register of the slave device.
5. The master initiates a Read data/Write data from the device or to the device
All communication over the I-wire bus is master initiated. The communication over the 1-wire bus is
divided into timeslots of 60 microseconds. The 'Reset' pulse occupies 8 time slots. For starting-a com-
munication, the master asserts the reset pulse by pulling the 1-wire bus 'LOW' for at least 8 time slots
(480µs). If a 'slave' device is present on the bus and is ready for communication it should respond to the
master with a 'Presence' pulse, within 60µs of the release of the 'Reset' pulse by the master. The slave
device(s) responds with a 'Presence' pulse by pulling the I-wire bus 'LOW' for a minimum of I time
slot (60µs). For·writing a bit value of 1 on the I-wire bus, the bus master pulls the bus for 1 to 15µs and
then releases the bus for the rest of the time sJot. A bit value of 'O' is written on the bus by master pulling
the bus for a minimum of 1 time slot (60µs) and a maximum of 2 time slots (120µs). To Read a bit from
the slave device, the master pulls the bus 'LOW' for 1 to 15 µs. If the slave wants to send a bit value '1'
in response to the read request from the master, it simply releases the bus for the rest of the time slot. If
the slave wants to send a bit value 'O', it pulls the bus 'LOW' for the rest of the time slot.
2. 4.1. 5 Parallel Interface The on-board parallel interface is normally used for communicating with
peripheral devices which are memory mapped to the host of the system. The host processor/controller
of the embedded system contains a parallel bus and the device which supports parallel bus can directly
connect to this bus system. The communication through the parallel bus is controlled by the control sig-
nal interface between the device and the host. The 'Control Signals' for communication includes 'Read/
Write' signal and device select signal. The device normally contains a device select line and the device
becomes active only when this line is asserted by the host processor. The direction of data transfer (Host
to Device or Device to Host) can be controlled through the control signal lines for 'Read' and 'Write'.
Only the host processor has control over the 'Read' and 'Write' control signals. The device is normally
memmy mapped to the host processor and a range of address is assigned to it. An address decoder circuit
is used for generating the chip select signal for the device. When the address selected by the processor
is within the range assigned for the device, the decoder circuit activates the chip select line and thereby
the device becomes active. The processor then can read or write from or to the device by asserting the
corresponding control line (RD\ and WR\ respectively). Strict timing characteristics are followed for
parallel communication. As mentioned earlier, parallel communication is host processor initiated. If a
device wants to initiate the communication, it can inform the same to the processor through interrupts.
For this, the interrupt line of the device is conne_cted to the interrupt line of the processor and the cor-
responding intem1pt is enabled in the host processor. The width of the parallel interface is determined
by the data bus width of the host processor. It can be 4bit, 8bit, 16bit, 32bit oi64bit etc. The bus width
supported by the device should be same as that of the host processor. The bus interface diagram shown
in Fig. 2.30 illustrates the interfacing of devices through parallel interface.
 The Typical Embedded System

Data bus

Control signals

Address bus

x: Data bus width

y: Address bus width

Parallel data communication offers the highest speed for data transfer.

Z.4.2 External Communication Interfaces

The External Communication Interface refers to the different communication channels/buses used by
the embedded system to communicate with the external world. The following section gives an overview
of the various interfaces for external communication.
2.4.2.1 RS-232 C & RS-485 RS-232 C (Recommended Standard number 232, revision C from the
Electronic Industry Association) is a legacy, full duplex, wired, asynchronous serial communication
interface. The RS-232 interface is developed by the Electronics Industries Association (BIA) during the
early 1960s. RS-232 extends the UART communication signals for external data communication.
UART uses the standard TTL/CMOS logic (Logic 'High' corresponds to bit value I and Logic 'Low'
corresponds to bit value 0) for bit transmission whereas-R~-232 follows the EIA standard for bit trans-
mission. As per the BIA standard, a logic 'O' is represented with voltage between +3 and +25V and a
logic 'l' is represented with voltage between-3 and-25V. In BIA standard, logic 'O' is known as 'Space'
and logic 'l' as 'Mark'. The RS-232 interface defines various handshaking and control signals for com-
munication apart from the 'Transmit' and. 'Receive' signal lines for data communication. RS-232 sup-
ports two different types of connectors, namely; DB-9: 9-Pin connector and DB-25: 25-Pin connector.
Figure 2.31 illustrates the connector details for DB-9 and DB-25.

1 5 1 13
00000 0000000000000
0 0000 0 0 000000000000 0
6 9 14 25
DB-25
DB-9
0Fi9::~:s1) DB-9 and DB-25 RS-232 Connector Interface
 Introduction to Embedded Systems

The pin details for the two connectors are explained in the following table:

TXD
,,,,~,
• ' ; ~, l"""' '>?7 it\;ti~~~:~i;~tf?~
2
, " " ·."~
'~-- :--~~: ,-~. \ ' ··-f\{~·:;.~:\ ,;~:(~t,J/\~~; ···-i-i:._

Transmit Pin for Transmitting Serial Data

:-: , .. ,.

.RXI).·· 3 Ribeive Pmi~f Rtt~1½11f seria1 oara .·

7. 4 Request to send.

:-~~§(£
Secqndary TXD ___
R~f~h!~~,Jf~i~~~Ittw.faiY ·

NC 9 No Connection
NC·:'i··.;,,,. 10 corih~ction •
NC 11 No Conn.ection
NC 18 ·. No. Cohilection ·
NC 23 No Cofulection
NC 24 No Connection
NC 25 No Connection

RS-232 is a point-to-point communication interface and the devices involved in RS-232 communica-
tion are called 'Data Tenninal Equipment (DTE)' and 'Data Communication Equipment (DCE)'. If no
data flow control is required, only TXD and RXD signal lines and ground line (GND) are required for
data transmission and reception. The RXD pin of DCE should be connected to the TXD pin of DTE and
vice versa for proper data transmission.
If hardware data flow control is required for serial transmission, various control signal lines of the
RS-232 connection are used appropriately. The control signals are implemented mainly for modem
communication and some of them may not be relevant for other type of devices. The Request To Send
(RTS) and Clear To Send (CTS) signals co-ordinate the communication between DTE and DCE. When-
ever the DTE bas a data to send, it activates the RTS line and if the DCE is ready to accept the data, it
activates the CTS line.
 The Typical Embedded System

The Data Terminal Ready (DTR) signal is activated by DTE when it is ready to accept data. The Data
Set Ready (DSR) is activated by DCE when it is ready for establishing a communication link. DTR
should be in the activated state before the activation of DSR.
The Data Carrier Detect (DCD) control signal is used by the DCE to indicate the DTE that a good
signal is being received.
Ring Indicator (RI) is a modem specific signal line for indicating an incoming call on the telephone
line.
The. 25 pin DJ3 connector contains two sets of signal lines for transmit, receive and control lines.
Nowadays DB-~5 connector is obsolete and most of the desktop systems are available with DB-9 con-
nectors only.
As pe~the BIA standard RS-232 C supports baudrates up to 20Kbps (Upper limit 19.2 Kbps) The com-
monly used baudrates by devices are 300bps, 1200bps, 2400bps, 9600bps, l l.52Kbps and 19.2Kbps.
9600 is the popularbaudrate setting used for PC communication. The maximum operating distance sup-
ported by RS-232 is 50 feet at the highest supported baudrate.
Embedded devices contain a UART for serial communication and they generate signal levels con-
forming to TTL/CMOS logic. A level translator IC like MAX 232 from Maxim Dallas semiconductor
is used for converting the signal lines from the UART to RS-232 signal lines for communication. On
the receiving side the received data is converted back, to digital logic level by a converter IC. Converter
chips contain converters for both transmitter and receiver.
Though RS-232 was the most popular communication interface during the olden days, the advent of
other communication techniques like Bluetooth, USB, Firewire, etc are pushing down RS-232 from the
scenes. Still .RS-232 is popular in certain legacy indusJrial applications.
RS-232 supports only point-to-point communication and not suitable for multi-drop communication.
It uses single ended data transfer technique for signal transmission and thereby more susceptible to
noise and it greatly reduces the operating distance.
RS-422 is another serial interface standard from EIA for differential data communication. It supports
data rates up to 1O0Kbps and distance up to 400 ft. The same RS-232 connector is used at the device
end and an RS-232 to RS-422 converter is plugged in the transmission line. At the receiver end the
conversion from RS-422 to RS-232 is performed. RS-422 supports multi-drop communication with one
transmitter device and receiver devices up to 10.
RS-485 {s the enhanced version of RS-422 and it supports multi-drop communication with up to 32
transmitting devices (drivers) and 32 receiving devices on the bus. The communication between devices
in the bus uses the 'addressing' mechanism to identify slave devices.
2.4.2.2 Universal Serial Bus (USE). Universal Serial Bus (USB) is a wired high speed serial bus
for data communication. The first version of USB (USB 1.0) was released in 1995 and was created by
the USB core group members consisting oflntel, Microsoft, IBM, Compaq, Digital and Northern Tele-
com. The USB communication system follows a star topology with a USB host at the centre and one
or more USB peripheral devices/USE hosts connected to it. A USB host can support connections up to
127, including slave peripheral devices and other USB hosts. Figure 2.32 illustrates the star topology
l for USB device connection.
l USB transmits data in packet format. Each data packet has a standard format. The USB communica-
tion is a host initiated one. The USB host contains a host controller which is responsible for controlling
t the data communication, including establishing connectivity with USB slave devices, packetizing and
fom1atting t~e data. There are different standards for implementing the USB Host Control interface;
namely Open Host Control Interface (OHCI) and Universal Host Control Interface (UHCI).
 Introduction to Embedded Systems

~
The physical connection between a USB peripheral de-
vice and master device is established with a USB cable.
The USB cable supports communication distance of up to Peripheral
5 metres. The USB standard uses two different types of device 2 I

connector at the ends of the USB cable for connecting the

USB peripheral device and host device. 'Type A' connector
is used for upstream connection (connection with host) and
I
Type B connector is used for downstream connection·(con-
~ection with slave device). The USB connector present in
Peripheral USB host Peripheral l
desktop PCs or laptops are examples for 'Type A' USB
connector. Both Type A and Type B connectors contain 4
device 1 (Hub) device 3
I
pins for communication. The Pin details for the connectors
_are li~ted in the table given below.
I
Peripheral
device 4
Peripheral
device 5
I
'
.

USB uses differential signals for data transmission. It

improves the noise immunity. USB interface has the abil_ity to supply power to the connecting devices.
Two connection lines (Ground and Power) of the USB interface are dedicated for carrying power. It can
supply power up to 500 mA at 5 V. It is sufficient to operq:te low power devices. Mini and Micro USB
'
connectors are available for small form factor devices liki portable media players.
Each USB device contains a Product ID (PID) and a ¼ndor ID (VID). The PID and VID are embed-
ded into the USB chip by the USB device manufacturer. The VID for a device is supplied by the USB
standards forum. PID and VID are essential for loading the drivers corresponding to a USB device for
communication.
USB supports four different types of data transfers, namely; Control, Bulk, Isochronous and Inter-
rupt. Control transfer is used by USB system software to query, configure and issue commands to the
USB device. Bulk transfer is used for sending a block of data to a device. Bulk transfer supports error
checking and correction. Transferring data to a printeds an example for bulk transfer. Isochronous data
transfer is used for real-time data communication. In Isochronous transfer, data is transmitted as streams
in r:eal-time. Isochronous transfer doesn't support error checking and re-transmission of data in case of
any transmission loss. All streaming devices like audio devices and medical equipment for data collec-
tion make use of the isochronous transfer. Interrupt transfer is used for transferring small amount of
data. Interrupt transfer mechanism makes use of polling technique to see whether the USB device has
any data to send. The frequency of polling is determined by the USB device and it varies from 1 to 255
milliseconds. Devices like Mouse and Keyboard, which transmits fewer amounts of data, uses Interrupt
transfer.
USB.0RG (www.usb.org) is the standards body for defining and controlling the standards for USB
communication. Presently USB supports four different data rates namely; Low Speed (1.5Mbps), Full
Speed (12Mbp's), High Speed (480Mbps) and Super Speed (4.8Gbps). The Low Speed and Full Speed
specifications are defined by USB 1.0 and the High Speed specification is defined by USB 2.0. USB 3.0
r
I
!

The Typical Embedded System

defines the specifications for Super Speed. USB 3.0 is expected to be in action by year 2009. There is a
move happening towards wireless USB for data transmission using Ultra Wide Band (UWB) technol-
ogy. Some laptops are already available in the market with wireless USB support.
2.4.2.3 IEEE 1394 (Firewire) IEEE 1394 is a wired, isochronous high speed serial communica-
tion bus. It is also known as High Performance Serial Bus (HPSB). The research on 1394 was started
by Apple Inc. in 1985 and the standard for this was coined by IEEE. The implementation of it is avail-
able from. various players with different names. Apple Inc's (www.apple.com) implementation of 1394
protocol is popularly known as Firewire. i.LINK is the 1394 implementation from Sony Corporation
(www.sony.net) and Lynx is the implementation from Texas Instruments (www.ti.com). 1394 supports
peer-to-peer connection and point-to-multipoint communication allowing 63 devices to be connected
on the bus in a tree topology. 13 94 is a wired serial interface and it can support a cable length of up to
15 feet for interconnection.
The 1394 standard has evolved a lot from the first version IEEE 1394-1995 released in 1995 to the
recent version IEEE 1394-2008 released in June 2008. The 1394 standard supports a data rate of 400
to 3200Mbits/second. The IEEE 1394 uses differential data transfer (The infonnation is sent using dif-
ferential signals through a pair of twisted cables. It increases the noise immunity) and the interface cable
supports 3 types of connectors, namely; 4-pin connector, 6-pin connector (alpha connector) and 9 pin
connector (beta connector). The 6 and 9 pin connectors carry power also to support external devices
(In case an embedded device is connected to a PC through an IEEE 1394 cable with 6 or 9 pin connec-
tor interface, it can operate from the power available through the connector.) It can supply unregulated
power in the range of 24 to 30V. (The Apple implementation is for battery operated devices and it can
supply a voltage in the range 9 to 12V.) The table given below illustrates the pin details for 4, 6 and 9
pin connectors.

. '

'',t1r

TPA(S) 5 Shield. for the uiffe,rential s1gnal line A.

Noqn~1lr:groun~~d , ,

There are two differential data transfer lines A and B per connector. In a 1394 cable, normally the dif-
ferential lines of A are connected to B (TPA+ to TPB+ and TPA-to TPB-) and vice versa.
1394 is a popular communication interface for connecting embedded devices like Digital Camera,
Camcorder, Scanners to desktop computers for data transfer and storage.
Unlike USB interface (Except USB OTG), IEEE 1394 doesn't require a host for communicating
between devices. For example, you can directly connect a scanner with a printer for printing. The data-
 Introduction to Embedded Systems

rate supported by 1394 is far higher than the one supported by USB2.0 interface. The 1394 hardware
implementation is much costlier than USB implementation.
2:4.2.4 Infrared (IrDA) Infrared (IrDA) is a serial, half duplex, line of sight based wireless tech-
nology for data communication between devices. It is in use from the olden days of communication
and you may be very familiar with it. The remote control of your TV, VCD player, etc. works on In-
frared data communication principle. Infrared communication technique uses infrared waves of the
electromagnetic spectrum for transmitting the data. IrDA supports point-point and point-to-multipoint
communication, provided all devices involved in the communication are within the line of sight. The
typical communication range for IrDA lies in the range 10 cm to 1 m. The range can be increased by
increasing the transmitting power of the IR device. IR supports data rates ranging from 9600bits/second
to 16Mbps. Depending on the speed of data transmission IR is classified into Serial IR (SIR), Medium
IR (MIR), Fast IR (FIR), Very Fast IR (VFIR) and Ultra Fast IR (UFIR). SIR supports transmission
rates ranging from 9600bps to 115.2kbps. MIR supports data rates of 0.576Mbps and l.152Mbps. FIR
supports data rates up to 4Mbps. VFIR is designed to support high data rates up to 16Mbps. The UFIR
specs are under development and it is targeting a-=data rate up to lO0Mbps.
IrDA communication involves a transmitter unit for transmitting the data over IR and a receiver
for receiving the data. Infrared Light Emitting Diode (LED) is the IR source for transmitter and at the
receiving end a photodiode acts as the receiver. Both transmitter and receiver unit will be present in
each device supporting IrDA communication for bidirectional data transfer. Such IR units are known as
'Transceiver'. Certain devices like a TV remote control always require unidirectional communication
and so they contain either the transmitter or receiver unit (The remote control unit contains the transmit-
ter unit and TV contains the receiver unit).
'Infra-red Data Association' (IrDA- http://www.irda.org/) is the regulatory body responsible for de-
fining and licensing the specifications for IR data communication. IrDA communication has two es-
sential parts; a physical link part and a protocol part. The physical link is responsible for the physical
transmission of data between devices supporting IR communication and protocol part is responsible
for defining the rules of communication. The physical link works on the wireless principle making use
of Infrared for communication. The IrDA specifications include the standard for both physical link and
protocol layer.
The IrDA control protocol contains implementations for Physical Layer (PHY), Media Access Con-
trol (MAC) and Logical Link Control (LLC). The Physical Layer defines the physical characteristics of
communication like range, data rates, power, etc.
IrDA is a popular interface for file exchange and data transfer in low cost devices. IrDA.was the
prominent communication channel in mobile phones before Bluetooth's existence. ·Even now most of
" mobile phone devices support IrDA.
the
2.4.2.S Bluetooth (BT) Bluetooth is a low cost, low power, short range wireless technology for data
and voice communication. Bluetooth was first proposed by 'Ericsson' in 1994. Bluetooth operates at
2AGHz of the Radio Frequency spectrum and uses the Frequency Hopping Spread Spectrum (FHSS)
technique for communication. Literally it supports a data rate of up to lMbps and a range of approxi-
mately 30 feet for data communication. Like IrDA, Bluetooth communication also has two essential
parts; a physical link part and a protocol part. The physical link is responsible for the physical trans-
mission of data between devices supporting Bluetooth communication and protocol part is responsible
 The Typical Embedded System

for defining the rules of communication. The physical link works on the wireless principle making use
of RF waves for communication. Bluetooth enabled devices essentially contain a Bluetooth wireless
radio for the transmission and reception of data. The rules governing the Bluetooth communication is
implemented in the 'Bluetooth protocol stack'. The Bluetooth communication IC holds the stack. Each
Bluetooth device will have a 48 bit unique identification number. Bluetooth communication follows
packet based data transfer.
Bluetooth supports point-to-point (device to device) and point-to-multipoint (device to multiple
device broadcasting) wireless communication. The point-to-point communication follows the master-
slave relationship. A Bluetooth device can function as either master or slave. When a n~twork is formed
with one Bluetooth device as master and more than one device as slaves, it is called a Piconet. A Piconet
supports a maximum of seven slave devices.
Bluetooth is the favourite choice for short range data communication in handheld embedded devices.
Bluetooth technology is very popular among cell phone users as they are the easie~t communication
channel for transferring ringtones, music files, pictures, media files, etc. between neighbouring Blue-
tooth enabled phones. · ·
The Bluetooth standard specifies the minimum requirements that a Bluetooth device must support
for a specific usage scenario. The Generic Access Profile (GAP) defines the requirements for detecting
a Bluetooth device and establishing a connection with it. All other specific usage profiles are based on
GAP. Serial Port Profile (SPP) for serial data communication, File Transfer Profile (FTP) for file transfer
between devices, Human Interface Device (HID) for supporting human interface devices like keyboard
and mouse are examples for Bluetooth profiles. .
The specifications for Bluetooth communication is defined and licensed by the standards body 'Blue-
tooth Special Interest Group (SIG)'. For more information, please visit the website www.bluetooth.org.
2.4.2.6 Wi-Fi Wi-Fi or Wireless Fidelity is the popular wireless communication technique for net-
worked communication of devices. Wi-Fi follows the IEEE 802.11 standard. Wi-Fi is intended for net-
work communication and it supports Internet Protocol (IP) based communication. It is essential to have
device identities in a multipoint communication to address specific devices for data communication. In
an IP based communication each device is identified by an IP address, which is unique to each device on
the network. Wi-Fi based communications require an intermediate agent called Wi-Fi router/Wireless
Access point to manage the communications. The Wi-Fi router is responsible for restricting the access to
a network, assigning IP address to devices on the network, routing data packets to the intended devices
on the network. Wi-Fi enabled devices contain a wireless adaptor for transmitting and receiving data in
the form of radio signals through an antenna. The hardware part of it is known as Wi-Fi Radio.
Wi-Fi operates at 2.4GHz or 5GHz ofradio spectrum and they co-exist with other ISM band devicr:s
like Bluetooth. Figure 2.33 illustrates the typical interfacing of devices in a Wi-Fi network.
For communicating with devices over a Wi-Fi network, the device when its Wi-Fi radio is turned
ON, searches the available Wi-Fi network in its vicinity and lists out the Service Set Identifier (SSID) of
the available networks. If the network is security enabled, a password may be required to connect to a
particular SSID. Wi-Fi employs different security mechanisms like Wired Equivalency Privacy (WEP)
Wireless Protected Access (WPA), etc. for securing the data communication.
Wi-Fi supports data rates ranging from IMbps to l 50Mbps (Growing towards higher rates as technol-
ogy progresses) depending on the standards (802.11 alb/g/n) and access/modulation method. Depending
on the type of antenna and usage location (indoor/outdoor), Wi-Fi offers a range of 100 to 300 feet.
 Introduction to Embedded Systems

2.4.2. 7 ZigBee ZigBee is a low power, Wi-Fi router

low cost, wireless network communication
protocol based on the IEEE 802.15.4-2006
standard. ZigBee is targeted for low pow-
er, low data rate and secure applications
for Wireless Personal Area Networking
(WPAN). The ZigBee specifications support
/
a robust mesh network containing multiple·
nodes. This networking strategy makes the ''
network reliable by permitting messages to
travel through a number of different paths to
/· ''
get from one node to another.
ZigBee operates worldwide at the unli- '
censed bands of Radio spectrum, mainly at
2.400 to 2.484 GHz, 902 to 928 MHz and Device 1
868.0 to 868.6 MHz. ZigBee Supports an Device 3
Device 2
operating distance ofup to 100 metres and a 1
data rate of 20 to 250Kbps. (i:rig. 2!sa) Wf~l'riie~rlt
In the ZigBee terminology, each ZigBee
device falls under any one of the following ZigBee device category.
ZigBee Coordinator (ZC)/Network Coordinator: The ZigBee coordinator acts as the root of the Zig-
Bee network. The ZC is responsible for initiating the ZigBee network and it has the capability to ·store
information about the network.
ZigBee Router (ZR)/Full function Device (FFD): Responsible for passing information from device to
another device or to another ZR.
ZigBee End Device (ZED)/Reduced Function Device (RFD): End device containing ZigBee func-
tionality for data communication. It can talk only with a ZR or ZC and doesn't have the capability to act
as a mediator for transferring data from one device to another.
The diagram shown in Fig. 2.34 gives an overview of ZC, ZED ZED
ZED and ZR in a ZigBee network.
ZigBee is primarily targeting !!I1plication areas like home
& industrial automation, energy management, ho~e control/
security, medical/patient tracking, logistics & asset tracking
and sensor networks & active RFID. Automatic Meter Reading
(AMR), smoke detectors, wireless telemetry, HVAC control,
heating control, lighting controls, environmental controls, etc.
are examples for applications which can make use of the Zig-
Bee technology. ZED ZED
The specifications for ZigBee is developed and managed by ( Fig. 2.34) A ZigBe~ network model
the ZigBee alliance (www.zigbee.org), a non-profit consortium
of leading semiconductor manufacturers, technology providers, OEMs and end-users worldwide.
2.4.2.8 General Packet Radio Service (GPRS) General Packet Radio Service (GPRS) is a com-
munication technique for transferring data over a mobile communication network like GSM. Data is
sent as packets in GPRS communication. The transmitting device splits the data into several related
packets. At the receiving end the dafa is re-constructed by combining the received data packets. GPRS
 The Typical Embedded System

supports a theoretical maximum transfer rate of 171.2kbps. In GPRS communication, the radio channel
is concurrently shared between several users instead of dedicating a radio channel to a cell phone user.
The GPRS communication divides the channel into 8 timeslots and transmits data over the available
channel. GPRS supports Internet Protocol (IP), Point to Point Protocol (PPP) and X.25 protocols for
communication.
GPRS is mainly used by mobile enabled embedded devices for data communication. The device
should support the necessary GPRS hardware like GPRS modem and GPRS radio. To accomplish
GPRS based communication, the carrier network also should have support for GPRS communication.
GPRS is an old technology and it is being replaced by new generation data communication techniques
like EDGE, High Speed Downlink Packet Access (HSDPA), etc. which offers higher bandwidths for
communication.

Embedded firmware refers to the control algorithm (Program instructions) and or the configuration
settings that an embedded system developer dumps into the code (Program) memory of the embedded
system. It is an un-avoidable part of an embedded system. There are various methods available for de-
veloping the embedded firmware. They are listed below. ~
1. Write the program in high level languages like Embedded CIC++ using an Integrated Develop-
ment Environment (The IDE will contain an editor, compiler, linker, debugger, simulator, etc.
ID Es are different for different family of processors/controllers. For example, Keil micro vision3
IDE is used for all family members of 8051 microcontroller, since it contains the generic 8051
compiler CS I). .
2. Write the program in Assembly language using the instructions supported by your application's
target processor/contro Her.
The instruction set for each family of processor/controller is different and the program written in
either of the methods given above shfluld be converted into a processor understandable machine code
before loading it into the program memory.
The process of converting the program written in either a high level language or processor/controller
specific Assembly code to machine readable binary code is called 'HEX File Creation'. The methods
used for 'HEX File Creation' is different depending on the programming techniques used. If the pro-
gram is written in Embedded CIC++ using an IDE, the cross compiler included in the IDE converts it
into corresponding processor/controller understandable 'HEX File'. If you are following the Assembly
language based programming technique (method 2), you can use the utilities supplied by the proces-
sor/controller vendors to convert the source code into 'HEX File'. Also third party tools are available,
which may be of free of cost, for this conversion.
For a beginner in the embedded software field, it is strongly recommended to use the high level lan-
guage based development technique. The reasons for this being: writing codes in a high level language
is easy, the code written in high level language is highly portable which means you can use the same
code to run on different processor/controller with little or less modification. The only thing you need to
do is re-compile the program with the required processor's IDE, after replacing the include files for that
particular processor. Also the programs written in high level languages are not developer dependent.
Any skilled programmer can trace out the functionalities of the program by just having a look at the pro-
gram. It will be much easier if the source code contains necessary comments and documentation lines.
It is very easy to debug and the overall system development time will be reduced to a greater extent.
 Introductiqn to Embedded Systems

The embedded software development process in assembly language is tedious and time consuming.
The developer needs to know about all the instruction sets of the processor/controller or at least s/he
should carry an instruction set reference manual with her/him. A programmer using assembly language
technique writes the program according to his/her view and taste. Often he/she may be writing a method i
or functionality which can be achieved through a single instruction as an experienced person's point of
view, by two or three instructions in his/her own style. So the program will be highly dependent on the
developer. It is very difficult for a second person to understand the code written in Assembly even if it
is well documented. .
We will discuss both approaches of embedded software development in a later chapter dealing with
design of embedded-firmware, in detail. Two types of control algorithm design exist in embedded firm-
ware development. The first type of control algorithm development is Jsnown as the infinite loop or
'super loop' based approach, where the control flow runs from top to bottom and then jumps back to
the top of the program in a conventional procedure. It is similar to the while (1) { }; based technique
in C. The second method deals with splitting the functions to be executed into tasks and running these
tasks using a scheduler which is part of a General Purpose or Real Time Embedded Operating System
(GPOS/RTOS). We will discuss both of these approaches in separate chapters of this book.

The other system components refer to the components/circuits/ICs which are necessary for the proper
functioning of the embedded system. Some of these circuits· may be essential for the proper function-
ing of the processor/controlier and firmware execution. Watchdog timer, Reset IC (or passive circuit),
brown-out protection IC (or passive circuit), etc. are examples of circµits/ICs which are essential for
the proper functioning of the processor/controllers. Some of the controllers or SoCs integrate these
components within a single IC and doesn't require such components externally connected to the chip
for proper functioning. Depending on the system requirement, the embedded system may include other
integrated circuits for performing specific functions, level transl-a.tor ICs for interfacing circuits with
different logic levels, etc. The following section explains the essential circuits for the proper functioning
of the processor/controller of the embedded system.

2.6.1 Reset Circuit

The reset circuit is essential to ensure that the device is not operating at a voltage level where the device
is not guaranteed to operate, during system power ON. The reset signal brings the internal registers and
the different hardware systems of the processor/controller to a known state and starts the firmware exe-
cution from the reset vector (Normally from vector address 0x0000 for conventional processors/control-
lers. The reset vector can be relocated to an address for processors/controllers supporting bootloader).
The reset signal can be either active high (The processor undergoes reset when the reset pin of the pro-
cessor is at logic high) or active low (The processor undergoes reset when the reset pin of the processor
is at logic low). Since the processor operation is synchronised to a clock signal, the reset pulse should
be wide enough to give time for the clock oscillator to stabilise before the internal reset state starts.
The reset signal to the processor can be applied at power ON through an external passive reset circuit
comprising a Capacitor and Resistor or through a standard Reset IC like MAX810 from Maxim Dallas
(www.maxim-ic.com). Select the reset IC based on the type ofreset signal and logic level (CMOS/TTL)
supported by the processor/controller in use. Some microprocessors/controllers contain built-in internal
 The Typical Embedded System

reset circuitry and they don't require external reset circuitry. Figure 2.35 illustrates a resistor capacitor
based passive reset circuit for active high and low configurations. The reset pulse width can be adjusted
by changing the resistance value R and capacitance value C.

Vee
+±Vee
bl)
C .El
Reset pulse a) (\)
(\) "O
.Cl 0
R
Q)
Active high :3:
Q) ·-
"O
0 "O
:a £ Reset pulse
bl) R
-
.El
( \)
(\)
+
Active low

1(\)
Q)
C
....
µ.;
GND

2.6.2 Brown-out Protection Circuit

Brown-out protection circuit prevents the processor/controller
from unexpected program execution behaviour when the sup-
ply voltage to the processor/controller falls below a specified
voltage. It is essential for battery powered devices since there
are greater chances for the battery voltage to drop below the
required threshold. The processor behaviour may not be pre-
dictable if the supply voltage falls below the recommended op- Q
erating voltage. It may lead to situations like data corruption. A
Reset pulse
brown-out protection circuit holds the processor/controller in
Active low
reset state, when the operating voltage falls below the thresh- Dz
old, until it rises above the threshold voltage. Certain proces- R3'
sors/controllers support built in brown-out protection circuit
which monitors the supply voltage internally. If the proces-
sor/controller doesn't integrate a built-in brown-out protection
circuit, the same can be implemented using external passive ( Fig. 2.36) Brown-out protection circuit
circuits or supervisor ICs. Figure 2.36 illustrates a brown-out with Active low output
circuit implementation using Zener diode and transistor for
processor/controller with active low Reset logic.
The Zener diode Dz and transistor Q forms the heart of this circuit. The transistor conducts always
when the supply voltage Vee is greater than that of the sum of V8 E and V2 (Zener voltage). The transistor
stops conducting when the supply voltage falls below the sum of V8 E and Vz. Select the Zener diode
with required voltage for setting the low threshold value for Vee. The values of Rl, R2, and R3 can
be selected based on the electrical characteristics (Absolute maximum current and voltage ratings) of
the transistor in use. Microprocessor Supervisor ICs like DS1232 from Maxim Dallas (www.maxim-
ic.com) also provides Brown-out protection.
 f

Introduction to Embedded Systems

2.6.3 Oscillator Unit

A microprocessor/microcontroller is a digital device made up of digital combinational and sequential
circuits. The instruction execution of a microprocessor/controller occurs in sync with a clock signal. It is
analogous to the heartbeat of a living being which synchronises the execution oflife. For a living being,
the heart is responsible for the generation of the beat whereas the oscillator unit of the embedded system
is responsible for generating the precise clock for the processor. Certain processors/controllers integrate
a built-in oscillator unit and simply require an external ceramic resonator/quartz crystal for producing
the necessary clock signals. Quartz crystals and ceramic resonators are equivalent in operation, however
they possess physical difference. A quartz crystal is normally mounted in a hermetically sealed metal
case with two leads protruding out of the case. Certain· devices may not contain a built-in oscillator unit
and require the clock pulses to be generated and supplied externally. Quartz crystal Oscillators are avail-
able in the form chips and they can be used for generating the clock pulses in such a cases. The speed
of operation of a processor is primarily dependent on the clock frequency. However we cannot increase
the clock frequency blindly for increasing the speed of execution. The logical circuits lying inside the
processor always have an upper threshold value for the maximum clock at which the system can run,
beyond which the system becomes unstable and non functional'. The total system power consumption
is directly proportional to the clock frequency. The power consumption increases with increase in clock
frequency. The accuracy of program execution depends on the accuracy of the clock signal. The accu-
racy of the crystal oscillator or ceramic resonator is normally expressed in terms of +/-ppm (Parts per
million). Figure 2.37 illustrates .the usage of quartz crystal/ceramic resonator and external oscjllator chip
for clock generation.

C : Capacitor
Y : Resonator

Crystal oscillator

Quartz crystal fl.Jl Clock input pin

resonator

( Fig. 2.37) Oscillator circuitry using quartz crystal and quartz crystal oscillator

2.6.4 Real-Time Clock (RTC)

Real-Time Clock (RTC) is a system component responsible for keeping track of time. RTC holds infor-
mation like current time (In hours, minutes and seconds) in 12 hour/24 hour format, date, month, year,
day of the week, etc. and supplies timing reference to the system. RTC is intended to function even in
the absence of power. RT Cs are available in the form of Integrated Circuits from different semiconduc-
tor manufacturers like Maxim/Dallas, ST Microelectronics etc. The RTC chip contains a microchip for
holding the time and date related information and backup battery cell for functioning in the absence of
power, in a single IC package. The RTC chip is interfaced to the processor or controller of the embedded
system. For Operating System based embedded devices, a timing reference is essential for synchronising
 The Typical Embedded System

the operations of the OS kernel. The RTC can interrupt the OS .kernel by asserting the interrupt line
of the processor/controller to which the RTC interrupt line is connected. The OS kernel identifies the
interrupt in terms of the Interrupt Request (IRQ) number generated by an interrupt controller. One IRQ
can be assigned to the RTC interrupt and the kernel can perform necessary operations like system date
time updation, managing software timers etc when an RTC timer tick interrupt occurs. The RTC can be
configured to interrupt the processor at predefined intervals or to interrupt the processor when the RTC
register reaches a specified value (used as alarm interrupt).

2.6.5 Watchdog:Timer
In desktop Windows systems, ifwe feel our application is behaving in an abnonnal way or if the system
hangs up, we have the 'Ctrl +Alt+ Del' to come out of the situation. What if it happens to our embed-
ded system? Do we really have a 'Ctrl +Alt+ Del' to take control of the situation? Of course not®, but
we have a watchdog to monitor the firmware execution and reset the system processor/microcontroller
when the program execution hangs up. A watchdog timer, or simply a watchdog, is a hardware timer for
monitoring the firmware execution. Depending on the internal implementation, the watchdog timer in-
crements or decrements a free running counter with each clock pulse and generates a reset signal to reset
the processor if the count reaches zero for a down counting watchdog, or the highest count value for an
upcounting watchdog. If the 'Yatchdog counter is in the enabled state, the firmware can write a zero (for
upcounting watchdog implem~ntation) to it before starting the execution of a piece of code (subroutine
or portion of code which is susceptible to execution hang up) and the watchdog will start counting. If the
finnware execution doesn't cohiplete due to malfunctioning, within the time required by the· watchdog
to reach the maximum count, the counter will generate a reset pulse and this will reset the processor
(if it is connected to the reset line of the processor). If the firmware execution completes before the
expiration of the watchdogJimer you can reset the count by writing a O (for an upcounting watchdog
· timer) to the watchdog timer register. Most of the processors implement watchdog as a built-in compo-
nent and provides status register to control the watchdog timer (like enabling and disabling watchdog
functioning) and watchdog timer register for writing the count value. If the processor/controller doesn't
contain a built in watchdog timer, the same can be implemented using an external watchdog timer IC
circuit. The external watchdog timer uses hardware logic for enabling/disabling, resetting the watch-
dog count, etc instead of the firmware based 'writing'· to the status and watchdog timer register. The
Microprocessor supervisor IC DS1232 integrates a hardware watchdog timer in it. In modern systems
running on embedded operating systems, the watchdog can be implemented in such a way that when
a watchdog timeout occurs, an interrupt is generated instead of resetting the processor. The intenupt
handler for this handles the situation in an appropriate fashion. Figure 2.38 illustrates the implementa-

.Mi2r9pr~t;esi~fI ·
.· ..:eoutrhiter·
t~, :--"··:... ;._f.''.i--tf~:'.·"?_"
Arr

Free riinhirrg

Watchdog Reset

System clock
(fig. 2.38) Watchdog timer for firmware execution supervision
 Introduction to Embedded Systems

tion of an external watchdog timer based microprocessor supervisor circuit for a small scale embedded
system.

2.7· PCB \AND PASSIVE COMPONENTS

Printed Circuit Board (PCB) is the backbone of every embedded system. After finalising the components
and the inter-connection among them, a schematic design is created and according to the schematic the
PCB is fabricated. This will be described in detail in a chapter dedicated for "Embedded Hardware
Design and Development". PCB acts as a platfom1 for mounting all the necessary components as per
the design requirement. Also it acts as a platfor;m for testing your embedded firmware. Apart from the
above-mentioned important subsystems of an embedded system, you can find some passive electronic
components like resistor, capacitor, dio<;l.es, etc. on your board. They are the co-workers of various
chips contained in your embedded h.::rdware. They are very essential for the proper functioning of your
embedded system. For example for providing a regulated ripple-free supply voltage to the system, a
regulator IC and spike suppressor filter capacitors are very essential.

Summary
, ' . •,•· ) . , ,. .<,_ . .-,.: ' . ' ' ,7 ,J1,:,?:,:/"':"::~~}_'_::,:
✓ The core of an embedded S)'.Stem is u~ti~lly b~Ht a(9und.a ,c9qu:ti~rcial off:pJ:he-$helfcpmpon~nt,or an . app!i2~!iin
specific integrated circuit (ASIC) p{i generil'ptiip'ose'pdiles~or'Jike ~tcroprocessor 01' mjc~6oµtil{If,\ '.t'",·
' --~- . . , •' . \_ , ',~.'"':''J:"I•.,.:{-~ qi'\/;:'\ _v_;\,
a
''.,_f:, )< _:,.:-•: i -1;, ;<{;,.: f, !J<;_'>-'<<>•'f}
application'.·specific instruction set pmctssors (ASIP,1,ike DSP, Mi2rocontrollef'etc.} or a Pr.9gr~~glt1,3
Devtce (PLD)or a System oh Chip (SoC) · ·· · · ,. · ·. .· . · · . . :;. ,. ···
✓ Processors/controllers support either Reduced Instruction Set Computing (RISC).or ·CoQ1plex'I[~· '"\,:',:JR•c'/:;,;;t
Computing (CISC) .. . . i .. ·· .. · · · · ·1' •1••
✓ Micrapfoc~ssors/c6ntrollers based on the Harvard fuchitectu~e will ha.ve separate data'busand instrti'
wher~as M~◊roprocessors/contibllers based on the\Ton-Neumann ~chitecture shares single ;corii111ort·; a
fotcliing·boih instructions aria data . .
'•'"
✓ The Big-endian processors store the higher-order byte of the data in memocy at the lowest address, where;ts
Little-endian processors store the lower-order byte of data in memory at the lowest aqdress
✓ Field Programmable Gate· Arrays (FPGAs). and Complex Programmable Logic Devices (CPLDs) are the two
major types of programmable logic devices
✓ The Read Only Memory (ROM) is a non-volatile memocy for storing the firmware and embedded OS files.
MROM, PROM (OTP), EPROM, EEPROM and FLASH are the commonly used firmware storage memory
✓ Random.Access Memory (RAM) is a volatile memory for temporary data storage. RAM can be either Static
RAM (SRAM) or Dynamic RAM (DRAM). SRAM is made up offlip-flops, \Vhereas DRAM is made up of MOS
Transistor and Capacitor
✓ The sensors connected to the input port of an embedded system senses the changes in input variables and the
actuators connected at the output port of an embedded system controls some variables in accordance with changes
in input
✓ Light Emitting Diode (LED), 7-Segment LED displays, Liquid Crystal Display (LCD), Piezo Buzzer, Speaker,
Optocoupler, Stepper Motor, Digital to Anaiog Converters (DAC), Relays etc are examples for output devices of
an embedded system
✓ Keyboard, Touch screen, Push Button switches, Optocoupler, Analog to Digital Converter (ADC) etc are
examples for Input devices in an embedded system
 The Typical Embedded System

I ✓ The Programmable Peripheral Interface (PPI) device extends the I/0 capabilities of the processor used in
embedded system
✓ I2C, SPI, UART, I-Wire, Parallel bus etc are examples for onboard communication interface and RS-232C,
RS-485, USB, IEEE1394 (FireWire), Wi-Fi, ZigBee, Infrared (IrDA), Bluetooth, GPRS, etc. are examples for
external communication interface ·
✓ The control algorithm for the embedded device is known as Embedded Firmware.-Embedded firmware can be
developedGn. top .of an embeddyd operating system or without an operating system
✓ The reset circuit ensures that.the device is not operating at a wltage level wherethe device is not guaraQtee<l
to operate, during system power GN:The'reset·sigrtafbril').gs;tlle.mterria:l registers and the different hatdW'are .
systems of theprocessor/controller tq a knoWQ. state and st:arts the firmware execution from thMeset vectors' . '
✓ fhebrown:out protec:tion citcuitpreventsilie pro~ssoiicohtrJll~ffr<iin unexpected prograniexe~ution beha:yipur
a
. when the supply voltage to the processot/cohtroiler falls'below SIJ(:ilfied foltage . .. .· . . .
✓ The oscillat6r unit geherates clock signals for synchlori:ifilng the.operations of tiie processor
r
✓ The time keeping activity for the embedded sy,stem is perf6rm~d by .the Reai Time Clock (RTC) of the syst~rit
l RTC.holds currentti~e, date, month, year, day of the week, etc. . , • ··.
✓ The watchdog timer monitors the firmware execution ahd resets the processor or generates an Interrupt it. ca~e
the execution time for a task is exceeding the maximum allowed limit
✓ Printed circuit board or PCB acts as a platform for mounting all the necessary hardware components as per.the
design requirell!e~L ~~

c~) Keywords )
COTS Commercial-off-the-Shelf. Commercially available ready to use component
ASIC : Application Specific Integrated Circuit is a microchip designed to perform a specific or unique
application ·
ASSP : Application Specific Standar~ Product~An ASIC marketed to multiple customers just as a
general-purpose product is, but to a smaJler number of customers
Microprocessor : A silicon chip representing a Central Processing Unit (CPU)
GPP : General Purpose Processor or GPP is a processor designed for general computational tasks
ASIP : Application Specific Instruction Set processors are processors with architecture and instruction
set optimized to specific domain/application requirements
Microcontroller : A highly integrated chip that contains a CPU, scratchpad RAM, Special and General purpose
Register Arrays and Integrated peripherals
DSP : Digital Signal Processor is a powerful special purpose 8/16/32 bit microprocessors designed
specifically to meet the computational demands and power constraints
RISC : Reduced lnstrnction Set Computing. Refers to processors with Reduced and Orthogonal
Instruction Set
CISC : Refers to processors with Complex Instruction Set Computing
Harvard : A type of processor architecture with separate buses for program instruction and data
Architecture fetch
Von-Neumann : A type of processor architecture with a shared single common bus .for fetching both
Architecture instructions and data
f Big-Endian : Refers to processors which store the higher-order byte of the data in memory at the lowest
addr~ss
Little-Endian : Refdrs to processors which store the lower-order byte of the data in memory at the lowest
address
 Introduction to Embedded Systems

FPGA : Field Programmable Gate Array Device. A programmable logic device with reconfigurable
function. Popular for prototyping ASIC designs
MRQM : Masked ROM is a one-time programmable memory, which us.es the hardwired technologyfqf
storing data .
OTP : One Time Programmable Read Only Memory made up of nichrome or polysilicon wires . ,·" '>/·

arranged in a matrix
.EPROM : Era\able Programmable Read Only Memory. Reprogrammable ROM. Erased by exposing),to'
w~ J~
EEP~Ql\f : El(lctricaUy Erasab,le Prograrpmable Read Only Memory. Reprogra[J1m1:1ble ROM. Erascxf~y{
.applying.electrical sign~ls . .. . , . ·..
J[LASH / ; .Efoctrically Erasable PrograIUQ1able 'Re~d ,()nly M<rmory. S,i,tme as EEPRQM but wit.h
.. · . capacity inc1,s11pport for b,lock level meniory er1:1~hig , . . . .. . · ...
RAM : R~dom Acqess m~mory. Volatik m~mory · . ..
SRAM. : Static RAM. A type of RAM, made up of flip::.fiops
DR41V1, : Dynamic RAM: A~ ofRAM,made up o.fMOS Tr~nsistor a~d Capacitor
NVRAM : Non-volatikSRAM . Battery~ba.cked SRAM
ADC : Analog to Digital Converter. An integrated circuit which converts analog signals to
fonn
LED : Light Emitting Diode. An output device which produces visual indication.in the fonn ofliglit
accordance with current flow .• · · · ·
7-Segment : The 7-segment LED display is an output device for displaying alpha numeric " "r""ir,sr-,··•·•
h

LED Display It contains 8 light-emitting diode (LED) sygrnents arranged in a special form
Optocoupler ·: A§:olid state device t6 isolate two.parts of a circuit. Optocoupler combines an LED and
transistor in a single housing (package) .
Stepper motor : .An electro-mechanical device which generates discrete displacement .(motion) in res1oortstrto;c1c
.electrical signals
Relay ·: An electro-mechanfcal device which acts as dynamic path selector for signals and power. ;
Piezo Buz:z;er : A piezo-electric .device for geµerating audio indication. It c9ntains a p1ezo-electric diaplrr~gm

Push Button
switch
PPI
whicli,::9roduces audible sound in response to the voltage applied to it
: A mechanical device for electric circuit 'make' and 'break' operation

: Programmable Peripheral Interface is a device for extending the I/0 capabilities of processors/
I
}
I

· controllers
l2C : The Inter Integrated Circuit Bus (I2C-Pronounced 'I square C') is a synchronous bi-directional
half duplex two wire serial interface bus.
SPI : The Serial Peripheral Interface Bus'(SPI) is a synchronous bi-directional full duplex four wire
serial interface bus
UART : TI1e Universal Asynchronous Receiver Transmitter is an asynchronous communication
implementation standard
1-Wire interface : An asynchronous half-duplex communication protocol developed by Maxim Dallas
Semiconductor. It is also known as Dallas I -Wire® protocol.
RS-232 C : Recommended Standard.number 232, revision C from the.Elec~onic Industry As~ociation,.is a
legacy, full duplex, wired, asyncbronous serial communication\nterface
RS-485 : The enhanced version of RS-232, which supports multi-dro1),,'.c~nn'munication with up to 32
transmitting devices (drivers) and 32 receiving devices on the bus
USB : Universal Serial Bus is a wired high speed serial b),ls:for,.data communication
IEEE 1394 : A wired, isochronous high speed serial qom,muni'ca~io,n bi'.is
Firewire : The Apple Inc. 's implementation of the 1394 protoco,l
I
l
!'
I
The Typical Embedded System

~,~~rf:'~~t~:.i~~~
I ~~}9~lf~g~tl?~.t~~wiriI~!~~YS~P1~~)~f .,i;etween
,AA~'.~Qio~~Qininl1-hicai10n··.·
.. . . oflcetl;rionmiiliiication

ell Objeciive Questions ]

1. Embedded hardware/software systems are basically designed to
(a) Regulate a physical variable (b) Change the state of some devices
(c) Measure/Read the state of a variable/device (d) Any/All of these
2. Little Endian processors
(a) Store the lower-order byte of the data at the lowest address and the higher-order byte of the data at the highest
address of memory ·
(b) Store the higher-order byte of the data at the lowest address and the lower-order byte of the data at the highest
address of memory
(c) Store both higher order and lower order byte of the data at the same address of memory
(d) None of these
3. An integer variable with value 255 is stored in memory location at 0x8000. The processor word length is 8 bits
and the processor is a big endian processor. The size of integer is considered as 4 bytes in the system. What is th<:
value held by the memory location 0x8000? •
(a) 0xFF (b) 0x00 (c) 0x0l (d) None of these
4. The instruction set of RISC processor is
(a) Simple and lesser in number (b) Complex and lesser in number
(c) Simple and larger in number (d) Complex and larger in number
5. Which of the following is true about CISC processors?
(a) The instruction set is non-orthogonal
(b) The number of general purpose registers is limited,
(c) Instructions are like macros in C language
(d) Variable length Instructions
(e) All of these
(f) None of these
 r
Introduction to Embedded Systems

6. Which of the following processor architecture supports easier instruction pipelining?

(a) Harvard (b) Von Neumann (c) Both of them (d) None of these
7. Microprocessors/controllers based on the Harvard architecture will have separate data bus and instruction bus.
This allows the data transfer and program fetching to occur simultaneously on both buses. State True or False
(a) True (b) False
8. Which of the following is one-time programmable memory?
(a) SRAM (b) PROM (c) FLASH (d) "tNRAM
9. Which of the following memory type is best suited for development purpose?
(a) EEPROM (b) FLASH (c) UVEPROM
· (d) OTP (e) (a) or (b)
10. EEPROM memory is alterable at byte level. State True or False
(a) True (b) False
11 .. Non-volatile RAM is a Random Access Memory with battery backup. State True or False
(a) True (b) False .
12. Execution of program from ROM is faster than the execution from RAM. State True or False
(a) True (b) False
13. Dynamic RAM stores data in the fonn of voltage. State True or False
(a) True (b) False
14. The control algorithm (Program instructions) and or the configuration settings that are kept in the code (Program)
memory of the embedded system are known as Embedded Software. State True or False
(a) True (b) False
15. Which of the following is an example for Wireless Communication interface?
(a) RS-232C (b) Wi-Fi (c) Bluetooth
(d) EEE1394 (e) both(b)and(c)
16. Which of the following is (are) examples for ApP,lication Specific Instruction set Processor(s)
(a) Intel Centrino (b) AtmelAutomotiveAVR
(c) AMDTurion (d) MicrochipCANPIC (e) Allofthese (t) both(b)and(d)
17. How many memory cells are present in lKb RAM
(a) 1024 (b) 8192 (c) 512 (d) 4096
(e) None of these
18. Which of the following memory supports Execute in Place (XIP)?,
' (a) EEPROM (b) NOR FLASH (c) NAND FLASH
(d) both (b) and (c) (e) None of these -
19. How many memory cells are present in lKb Serial EEPROM
(a) 1024 (b) 8192 (c) 512 (d) 4096
(e) None of these
20. Which of the following is (are) example(s) for the input subsystem of an embedded system dealing with digital
data?
0

(a) ADC (b) Optocoupler (c) DAC (d) All of them

(e) only(a)and(b)
21. Which of the following is (are) example(s) for the output subsystem of an embedded system dealing with digital
data?
(a) LED (b) Optocoupler (c) Stepper Motor (d) All of these
(e) only (a) and (c)
22. Which of the following is true about optocouplers
(a) Optocoupler acts as an input device only
(b) Optocoupler acts as an output device only • .
(c) Optocoupler can be used in both input and output circuitry·
(d) None of these ·.
 '
r
r:
'
I
r:··
'!
The Typical Embedded System

23. Which of the following is true about a unipolar stepper motor

(a) Contains only a single winding per stator phase (b) Contains two windings per stator phase
i
(c) Contains four windings per stator phase (d) None of these
I: 24. Which of the following is (are) true about normally open single pole relays?
~i (a) The circuit remains open when the relay is not energised
!<

\' (b) The circuit remains closed when the relay is energised
I;
(c) -There are two output paths
(d) Both (a) and (b) (e) None of these
25. What is the minimum number I/0 line required to interface a 16-Key matrix keyboard?
·(a) 16 . (b) 8 (c) 4 (d) 9
26. Which is the optimal row-column configuration for a 24 key matrix keyboard?
(a) 6 x 4 (b) 8 x 3 (c) 12 x 2 (d) 5 x 5
27 Which of!he.following is an example for on-board interface in the embedded system context?
(a) I2C (b) _Bluetooth (c) SPI (d) All of them
(e) Only (a) and (c)
28. What is the minimum number of interface lines required for implementing I2C interface?
(a) 1 (b) 2 (c) 3 (d) 4
29. What is the minimum number of interface lines required for implementing SPI interface?
(a) 2 (b) 3 (c) 4 (d) 5
30. Which of the following are synchronous serial interface?
(a) I2C (b) SPI (c) UART (d) A1r6ffuese
(eY- Only (a) and (b)
31. RS-232. is a synchronous serial interface. State True or False
(a) Tnie (b) False
32. What is the maximum number ofUSB devices that can be connected to a USB host?
(a} Unlimited (b) 128 ' (c) 127 (d) None of these
33. In the ZigBee"tletwork, which of the following ZigBee entity stores the information about the network?
(a) ZigBee Coord,inator (b)' ZigBee Router
(c) ZigBee Reduced Function Device (d) All of them
34. What is the theoretical maximum data rate supported by GPRS
(a) 8Mbps (b) 12Mbps (c) lOOKbps (d) l 7 l.2Kbps
35. GPRS communication divides the radio channel into _ _ _ _ timeslots
(a) 2 (b) 3 (c) 5 (d) 8
f
l
I.
al
it Review Questions
tt
1. Explain the components of a typical embedded system in detail
II 2. Which are the components used as the core of an embedded system? Explain the merits, drawbacks, if any, and the
l
ml r applications/domains where they are commonly used
l
i 3. What is Application Specific Integrated Circuit (ASIC)? Explain the role of ASIC in Embedded System design?
4. Wh"at is the difference between Application Specific Integrated Circuit (ASIC) Application Specific Standard
Product (ASSP)?
:;
.J,What is the difference between microprocessor and microcontroller? Explain the role of microprocessors aml
controllers in embedded system design?
6. What is Digital Signal Processor (DSP)? Explain the role of DSP in embedded system design?
7. What is the difference bet\1/een RISC and CISC processors? Give an example for el'!ch.

✓
 Introduction to Embedded Systems
~r
8. What is processor architecture? What are the different processor architectures available for processor/controller
design? Give an example for each.
9. What is the difference between big-endian and little-endian processors? Give an example of each.
10. What is Programmable Logic Device (PLD)? What are the different types of PLDs? Explain the role of PLDs in
Embedded System design.
'·:.:,'] 11. What is the difference between PLD and ASIC?
?~~ 12. What are the advantages of PLD over fixed logic device?
13. What are the different types of memories used in· Embedded System design? Explain the role of each. t
14. What are the different types of memories used for Program storage in Embedded System Design? t
15. What is the difference between Masked ROM . and OTP?
.
16. What is the difference between PROM and EPROM?
17. What are the advantages of FLASH over other program storage memory in Embedded System design? I
Ii
18. What is the difference between RAM and RO.M? .
19. What are the different types of RAM used for Embedded System design?
20. What is memory shadowing? What is its advantage? .
21. What is Sensor? Explain its role in Embedded System Design? Illustrate with an example.
22. What is Actuator? Explain its role in Embedded System Design? Illustrate with an example. I
23. What is Embedded Finnware? What are the different approaches available for Embedded Firmware development'.?
24. What is the 4ifference between General Purpose Processor (GPP) and Application Specific Instruction Set
Processor (ASIP). Give an example for both.
i
25. Explain the soncept of Load Store architecture and instruction pipelining.
26. Explain the operation of Static RAM (SRAM) cell.
27. Explain the merits and limitations of SRAM and DRAM as Random Access Memory.
I
28. Explain the -difference between Serial Access Memory (SAM) and Random Access Memory (RAM). Give an
example for both. "'
29. Explain the different factors that needs to be considered in the selection of memory for Embedded Systems.
30. Explain the different types of FLASH memory and their relative merits and de-merits.
31. Explain the different Input and output subsystems of Embedded Systems.
32. What is stepper motor? How is it different from ordinary de motor?
33. Explain the role of Stepper motor in embedded applications with examples.
34. Explain the different step modes for stepper motor.
35. What is Relay? What are the different types of relays available? Explain the role of relay in embedded
applications.
36. Explain the operation of the transistor based Relay driver circuit.
37. Explain the operation of a Matrix Keyboard.
38. What is Programmable Peripheral Interface (PPI) Device? Explain the interfacing of 8255 PPI with an 8bit
microprocessor/controller.
39. Explain the different on-board communication interfaces in brief.
40. Explain the-different external communication interfaces in brief.
41. Explain the sequence of operation for communicating with an I2C slave device.
42. Explain the difference between I2C and SPI communication interface.
43. Explain the sequence of operation for communicating with a 1-Wire slave device.
44. Explain the RS-232 Oserial interface in detail.
45. Explain the merits and limitations of Parallel port over Serial RS-232 interface.
46. Explain the merits and limitations of IEEE1394 interface over USB.
47. Compare the operation of ZigBee and Wi-Fi network.
48. Explain the role of Reset circuit in Embedded System.
49. Explain the role of Real Time Clock (RTC) in Embedded System.
50. · Explain the role ofWatchdofTimer in Embedded System.
The Typical Embedded System
 i
i

I
I
Ir
LEARNING OBJECTIVES
. ;•_:·;,,1,>~/:'.S~~::F~f7(~t~t~f'f;:1\ . :s:,::.t:\ ;: _·;¾f:F/?5?~>'(~.:,-
f
{ · Leafnt,h/EhcJPdctensti'cs {ies~J1tbg .an em.bedded system .·., . • .... ·•· · · ·.· .. f
✓. Leprn:the. npn-fti11,cti6nal. requirerri,1rt§. that:need$JO be add-{~Ssed in.the.f!eif§n . :' ~;'_ ~"-~:~~··(· :_,:'
✓ :t~p.fnihe)rn.porfiht qlfqlity ~tt~~¼tef,of tqe em~~dd~djY5:tfiflJhgJr·e~4si;t~ ~·e:· ., .f~~~f ,, . . a,11aiiiih9~
'

I
:fi1ode;) .:pf:ttM: :system J:th1f incllkles, ·Resp~tjs§,•Ahr~yghput, N~1h1bility,t• Main.taina. ,&~~~t}i? "
· /•}~t8
✓ {~dr,n t1re important quality attributes ofthe embedded ➔Ystetn that ne~ds to be· addressed.for the non-ofiera1~o/tJ[
mode (offline mode) of the system. fhis includes Testability, pebug-a/Jility, Evolvabflfty, •Portability, Time tojk¢.fg: ·.· •
. .type and market, Per unit cost and revenue, etc. . .. .
✓ Understand the Product Life Cycle {PLC)

No matter whether it is an embedded or a non-embedded system, there will be a set of characteristics

describing the system. The non-functional aspects that need to be addressed in embedded system design
are commonly referred as quality attributes. Whenever you design an embedded system, the design
should take into consideration of both the functional and non-functional aspects. The following topics
give an overview of the characteristics and quality attributes of an embedded system.

3.1 CHARACTERISTICS OF AN EMBEDDED SYSTEM

Unlike general purpose computing systems, embedded systems possess certain specific characteristics
• and these characteristics are unique to each embedded system. Some of the important characteristics of
an embedded system are:
l. Application and domain specific
2. Reactive and Real Time
3. Operates in harsh environments
4. Distributed
5. Small size and weight
6. Power concerns
 Characteristics and Quality Attributes of Embedded Systems

3.1.1 Application and Domain Specific

If you closely observe any embedded system, you will find that each embedded system is having certain
functions to perform and they are developed in such a manner to do the intended functions only. They
cannot be used for any other'purpose. It is the major criterion which distinguishes an embedded system
from a generalpurpose system. For example, you cannot replace the embedded control unit of your mi-
crowave oven with your air conditioner's embedded control unit, because the embedded control units of
microwave oven and airconditioner are specifically designed to perform certain specific tasks. Also you
cannot replace an embedded control unit developed for a particular domain say telecom with another
control unit designed to serve another domain like consumer electronics.

3.1.2 Reactive and Real Time

.As mentioned earlier, embedded systems are in constant interaction with the Real, world through sen-
sors and user-defined input devices which are connected to the input port of the system. Any changes
happening in the Real world (which is called an Event) are captured by the sensors or input devices in
Real Time and the control algorithm running inside the unit reacts in a designed manner to bririg the
controlled output variables to the desired level. The event may be a periodic one or an unpredicted one.
If the event is an unpredicted one then such systems should be designed in such a way that it should be
scheduled to capture the events without missing them. Embedded systems produce changes in output in
response to the changes in the input. So they are generally referred as Reactive Systems.
Real Time System operation means the timing behaviour of the system should be deterministic;
a
meaning the system should respond to requests or tasks.in know_n amount of time. A Real Time system
should not miss any deadlines for tasks or operations. It is not necessary that a11 embedded systems
should be Real Time in operations. Embedded applications or systems which are mission critical, like
flight control systems, Antilock Brake Systems (ABS), etc. are examples of Real Time systems: The
design of an embedded Real time system should take the worst case scenario into consideration.

3.1. 3 Operates in Harsh Environment

It is not necessary that all embedded systems should be deployed in controlled environments. The en-
vironment in which the embedded system deployed may be a dusty one or a high temperature zone or
an area subject to vibrations and shock. Systems placed in such areas should be capable to withstand
all these adverse operati_ng conditions. The design should take care of the operating conditions of the
area where the system is going to implement. For example, if the system needs to be deployed in a high
temperature zone, then all the components used in the system should be of high temperature grade. Here
we cannot go for a compromise in cost. Also proper shock absorption techniques should be provided to
systems which are going to be commissioned in places subject to high shock. Power supply fluctuations,
corrosion and component aging, etc. are the other factors that need to be taken into consideration for
embedded systems to work in harsh environments.

3.1.4 Distributed
The tepn distributed means that embedded systems may be a part of larg.er systems. Many numbers of
such Idistributed embedded systems form a single large embedded control unit. An automatic vending
macijine_is a typical example for this. The vending machine contains a card reader (for pre-paid vend-
ing systems), a vending unit, etc. Each of them are independent embedded units but they work together
 Introduction to Embedded Systems

to perform the overall vending function. Another example is the Automatic Teller Machine (ATM).
An ATM contains a card reader embedded unit, responsible for reading and validating the user's ATM
card, transaction unit for performing transactions, a currency counter for dispatching/vending currqncy
to the authorised person and a printer unit for printing the transaction details. We can visualise these as
independent embedded systems. But they work together to achieve a common goal.
Another typical example of a distributed embedded system is the Supervisory Cqntrol And Data
Acquisition (SCADA) system used in Control & Instrumentation applications, which contains physi-
cally distributed individual embe_dded control units connected to a supervisory module.

3.1.5 Small Size and Weight

Product aesthetics is an important factor in choosing a product. For example, when you plan to buy a
new mobile phone, you may make a comparative study on the pros and corns of the products available in
the market. Definitely the product aesthetics (size, weight, shape, style, etc.) will be one of the deciding
factors to choose a product. People believe in the phrase "Small is beautiful". Moreover it is convenient
to handle a compact device than a bulky product. In embedded domain also compactness is a significant
deciding factor. Most of the application demands small sized and low weight products.

3.1.6 Power Concerns

Power management is another important factor that needs to be considered in designing embedded
systems. Embedded systems should be designed in such a way as to minimise the heat dissipation by the
system. The production of high amount of heat demands cooling requiremeµts like cooling fans whi_ch
in tum occupies additional space and make the system oulky. Nowadays ultra low power components
are available in the market. Select the d~sign according to the low power components like low dropout
regulators, and controllers/processors with power saving modes. Also power management is a critical
constraint in battery operated application. The more the power consumption the less is the battery life.

Quality attributes are the non-functional requirements that need to be documented properly in any sys-
tem design. If the quality attributes are more concrete and measurable it will give a positive impact on
the system development process and the end product. The various quality attributes that needs to be
addressed in any embedded system development are broadly classified into two, namely 'Operational
Quality Attributes' and 'Non-Operational Quality Attributes'.

3.2.l Operational Quality Attributes

The operational quality attributes represent the relevant quality attributes related to the embedded sys-
tem when it is in the operational mode or 'online' mode. The important quality attributes coming under
this category are listed below:
1. Response
2. Throughput
3. Reliability
4. Maintainability
5. Security
6. Safety
 Characteristics and Quality Attributes of Embedded Systems

3.2.1.1 Response Response is a measure of quickness of the system. It gives you an idea about
how fast your system is tracking the changes in input vari.ables. Most of the embedded systems demand
fast response which should be almost Real Time. For example, an embedded system deployed in flight
~ontrol application should respond in a Real Time manner, Any responsl! delay in the system will cre-
ate potential damages to the safety of the flight as well as the passengers. It is not necessary that all
embedded systems should be Real Time in response. For example, the response time requirement for
an electronic toy is not at all time-critical. There is no specific deadline that this system should respond
wit~in this particular timeline.
3.2.1.2 Throughput Throughput deals with the efficiency of a system. In general it can be defined
as the rate of. production or operation of a defined process over a stated period of time. The rates can be
expressed iri. terms of units of products, batches produced, or any other meaningful measurements. In
the case of a Carq Reader, throughput means how mahy transactions the Reader can perform in a minute
or in ;in hour odn a day. Throughput is generally measured in terms of 'Benchmark'. A 'Benchmark' is
a reference point by which something can be measured. Benchmark can be a set of performance criteria
that a product is expected to meet or a standard product that can be used for comparing other products
of the same product line.
3.2.1. 3 Reliability Reliability is a measure of how much % you can rely upon the proper function-
ing of the system or what is the% susceptibility of the system to failures.
Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) are the terms used in de.~
fining system reliability. MTBF gives the frequency of failures in hours/weeks/months. MTfR specifies
how long the system is allowed to be out of order following a failure. For an embedded system with
critical application need, it should be of the order of minutes.
3.2.1.4 Maintainability Maintainability deals with support and maintenance to the end user or cli-
ent in case of technical issues and product failures or on the basis of a routine system checkup. Relh,1bility
and maintainability are considered as two complementary disciplines. A more reliable system means a
system with less corrective maintainability requirements and vice versa. As the reliability of the system
increases, the chances of failure and non-functioning also reduces, thereby the need for maintainabil-
ity is also reduced. Maintainability is closely related to the system availability. Maintainability can be
broadly classified into two categories, namely, 'Scheduled or Periodic Maintenance (preventive mainte-
nance)' and 'Maintenanc~ to unexpected failures (corrective maintenance)'. Some embedded products
may use consumable components or may contain components which are subject to wear and tear and
they should be replaced on a periodic basis. The period may be based on the total hours of the system us-
age or the total output the system delivered. A printer is a typical example for illustrating the two types of
maintainability. An inkjet printer uses ink cartridges, which are consumable components and as per the
printer manufacturer the end user should replace the cartridge after each 'n' number of printouts to get
quality prints. This is an example for 'Scheduled or Periodic maintenance'. If the paper feeding part
of the printer fails the printer fails to print and it requires immediate repairs to rectify this problem. This
is an example of 'Maintenance to unexpected failure'. In both of the maintenances (scheduled and
repair), the,printer needs to be brought offline and during this time it will not be available for the user.
Hence it is obvious that maintainability is simply an indication of the availability of the product for use.
In any embedded system design, the ideal value for availability is expresse4 as
 Introduction to Embedded Systems

Ai= MTBF/(MTBF + MTTR)

where Ai = Availability in the ideal condition, MTBF = Mean Time Bet\:veen Failures, and MTTR =
Mean Time To Repair
3.2. I .5 Security Confidentiality, 'Integrity', and 'Availability' (The term 'Availability' mentioned
here is not related to the term 'Availability' mentioned under the 'Maintainability' section) are the three
major measures of information security. Confidentiality deals with the protection of data and application
from unauthorised disclosure. Integrity deals with the protection of data and application from unautho-
rised modification. Availability deals with protection of data and application from unauthorized users.
A very good example of the 'Security' aspect in an embedded product is a Personal Digital Assistant
(PDA). The PDA can °be either a shared resource (e.g. PDAs used in LAB setups) or an individual
one. If it is a shared one there should be some mechanism in the form of a user name and password to
access into a particular person's profile-This is an example of' Availability'. Also all data and applica-
tions present in the PDA need not be accessible to all users. Some of them are specifically accessible to
administrators only. For achieving this, Administrator and user levels of security should be implemented
-An example of Confidentiality. Some data present in the PDA may be visible to all users but there may
not be necessary permissions to alter the data by the users. That is Read Only access is allocated to all
users-An example of Integrity.
3.2.1. 6 Safety 'Safety' and 'Security' are two confusing terms. Sometimes Y<?U may feel both of
them as a single attribute. But they represent two unique aspects in quality attributes. Safety deals with
the possible damages that can happen to the operators, public and the environment due to the breakdown
of an embedded system or due to the emission of radioactive ·or hazardous materials from the embedded
products. The breakdown of an embedded system may occur due to a hardware failure or a firmware
failure. Safety analysis is a must in product engineering to evaluate the anticipated damages and deter-
mine the best course of action to bring down the consequences of the damages to an acceptableleve1.
As stated before, some of the safety threats are sudden (like product breakdown) and some of them are
gradual (like hazardous emissions from the product).

3. 2. 2 Non-Operational Quality Attributes

The quality attributes that needs to be addressed for the product 'not' onihe 1:>asis of operational aspects
are grouped under this category. The important quality attributes coming under this category are listed
below.
1. Testability & Debug-ability
2. Evolvability
3. Portability
4. Time to prototype and market
. 5. Per unit and total cost.
3.2.2.1 Testability & Debug-ability Testability deals with how easily one can test his/her design,
application and by which means he/she can test it. For an embedded product, testability is applicable
to both the embedded hardware and :firmware. Embedded hardware testing ensures that the peripherals
and the total hardware functions in the desired manner, whereas firmware· testing ensures that the firm-
ware is functioning in the expected way. Debug-ability is a means of debugging the product as such for
figuring out the probable sources that create unexpected behaviour in the total system. Debug-ability
 Characteristics and Quality Attributes of Embedded Systems

has two aspects in the embedded system development context, namely, hardware level debugging and
firmware level debugging. Hardware debugging is used for figuring out the issues created by hardware
problems whereas firmware debugging is employed to figure out the probable errors that appear as a
result of flaws in the firmware.
3.2.2.2 Evolvability Evolvability is a term which is closely related to Biology. ,Evolvability is
referred as the non-heritable variation. For an embedded system, .the quality attribute 'Evolvability'
refers to the ease with which the embedded product (including firmware and hardware) can be modified
to take advantage of new firmware or hardware technologies.
3.2.2.3 Portability Portability is a measure of 'system independence'. An embedded product is said
to be portable if the product is capable of functioning 'as such' in various environments, target proces-
sors/controllers and embedded operating systems. The ease with which an embedded product can: be
ported on to a new platform is a direct measure of the re-work required. A standard embedded product
should always be flexible and portable. In embedded products, the term 'porting' represents the migra-
tion of the embedded firmware written for one target processor (e.g. Intel x86) to a different target pro-
cessor (say Hitachi SH3 processor). If the firmware is written in a high level language like 'C' with little
target processor-specific functions (operating system extensions or compiler specific utilities), it is very
easy to port the firmware for the new processor by replacing those 'target processor-specific functions'
with the ones for the new target processor and re-compiling the program for the new target processor-
specific settings. Re-compiling the program for the new target processor generates the new target pro-
cessor-specific machine codes. If the firmware is written in Assymbly Language for a particular family.
of processor (say x86 family), it will be very difficult to translate the assembly language instructions to
the new target processor specific language and so the portability is poor.
If you look into various programming languages for application development for desktop applica-
tions, you will see that certain applications developed on certain languages run only on specific operat-
ing systems and some of them run independent of the desktop operating systems. For example, applica-
tions developed using Microsoft technologies (e.g. Microsoft Visual using Visual studio) is capable
of running only on Microsoft platforms and will not function on other operating systems; whereas
applications developed using 'Java' from Sun Microsystems works on any operating system that
supports Java standards.
3.2.2.4 Time-to-Prototype and Market Time-to-market is the time elapsed between the concep-
tualisation of a product and the time at which the product is ready for selling (for commercial product)
or use (for non-commercial products). The commercial embedded product market is highly competitive
and time to market the product is a critical factor in the success of a commercial embedded product.
There may be multiple players in the embedded industry who develop products of the same category
(like mobile phone, portable media players, etc.). If you come up with a new design and if it takes long
time to develop and market it, the competitor product may take advantage of it with their product. Also,
embedded technology is one where rapid technology change is happening. If you start your design by
making use of a new technology and if it takes long time to develop and market the product, by the
time you market the product, the technology might have superseded with a new technology. Product
prototyping helps a lot in reducing time~to-market. Whenever you have a product idea, you may not be
certain about the feasibility of the idea. Prototyping is an informal kind of rapid product development in
which the important features of the product under consideration are developed. The time to prototype is
also another critical factor. If the prototype is dev~loped faster, the actual estirµated development time
 Introduction to Embedded Systems

can be brought down significantly. In order to shorten the time to prototype, make use of all possible
options like the use of off-the-shelf components, re-usable assets, etc.
3":2.2.S Per Unit Cost and Revenue
/ .
Cost is a factor which is closely monitored by both end user
(those who buy the product) and product manufacturer (those who build the product). Cost is a highly
sensitive factor for-con:u:nercial products. Any failure to position the cost of a commercial product at a
nominal r~te, may lead to the failure of the product in the market. Proper market study and cost benefit
analysis should be carried out before taking a decision on the per-unit cost of the embe.dded product
From a designer/product development company perspective the ultimate aim of a product is to generate
marginal profit. So the budget and total system cost should be properly balanced to provide a marginal
profit. Every embedded product has a product life cycle which starts with the design and development
phase.The product idea generation; prototyping, Roadmap definition, actual product design and devel-
opment are the activities carried out during this phase. During the design and development phase there
is only investment and no returns. Once the product is ready to sell, it is introduced to the market. This
stage is known as the Product Introduction stage. During the initial period the sales' and revenue will
be low. There won't be much competition and the product sales and revenue increases with time. In the
growth phase, the product grabs high market share. During the maturity phase, the growth and sales will
be steady and the revenue reaches at its peak. The Product Retirement/Decline phase starts with the drop
in sales volume; market share and revenue. The decline happens due to various reasons like competition
from ~imilar product with enhanced features or technology changes, etc. At some point of the decline
stage, the manufacturer announces discontinuing of the product. The qifferent stages of the embedded
products life cycle-revenµe, unit cost and profit in each stage-are represented in the following Product
Life-cycle graph. • ·

I I
Product I
Pmcluct I
Product Product
Growth
development I introduction I maturity retirement
I I
I I
I l
I I
<l)
;l
I I
~ I ':::-,.'<i'?I
<l)
;> J c,'11'
<l)
. I &, I
~ o0.;s. I
I
I ~<.; I
I I
l Unit cost I

(Fig. 3.J) Prod~c:t life cycle (PLP) curve

From the graph, it is clear that the total revenue increases from the product introduction stage to the
product maturity stage. The revenue peaks at the maturity stage and starts falling in the decline/retire-
ment ~tage. The unit cost is very high ·during the introductory stage (a typical example is cell phone; if
 Characteristics and Quality Attributes of Embedded Systems

you buy a new model of cell phone during its launch time, the price will be high and you will get the
same model with a very reduced price after three or four months of its launching). The profit increases
with increase in sales and attains a steady value and then falls with a dip in sales. You can see a negative
value for profit during the initial period. It is because during the product development phase there is only
investment and no returns. Profit occurs only when the total returns exceed the investment and operating
cost.

utes ofah efubeddecl syst~#i rqfers tbthe'ton\'.· .

atfonafmode pf:tll<fsys . . orlse, Throil
s 9f oper~ti9~~Jg4ill .. . . ·s:,1:h/'1':f:Ii
b~s of an ~ni~iild~ :§)';§!~JJ1.tef~r'~Jo:Q1~,
.. 9n-;operation~l::tnode J>L~e ·:~Y~t~~. i~sta
m~rket~
,
per uh{tco.sfarrd
· -
rev~iiµe,citc;iire•ei:
i~/;-:'-. ·'.·• ";'•::·,"":'.,,, .\.¥,,;. ,Jf:,,,,.---•,:-;·~- · •z,·:, -· ·_;

curve (ftE) i; }he :grap9it,1,r~~reseiii;tion of the u~it cost/ rodu

ifd .cycl~ stages 9f thej,fqgµcti~artil;(g~ftorp.9'0n~ep~9p}o::
'res,p~c;f. ·• . i ·.·•.·.. .
Feir i~omtt1et~1i,,,em edtled protluct,· the unit ~bst i~:p~ak at th~ introducldry';stag
srage. . ': ::
✓ The revenue ofa commercial e111bedded prod~c~·is at the peak _qµriligtl,i;e µ1aturity stag~;/

Quality attributes : The non-functional requirements that need to be addressed in any system design
Reactive system : An embedded system which produces changes in output in response to the 6haiiges in
input·
Real-Time system : A system 'which adheres to strict timing behaviour and responds to requests in a known
amount of time. ,
Response : It is a measure of quickness of the sys.tern
Throughput ·: The rate ofproductipn or operation of a defined process over a stated period of time
Reliability : It is a measure of how much\% one can rely upon the proper functioning ofa system
MTBF : Mean Time Between Failures\-The frequency of failures in hours/weeks/months "· · ·
MTTR : Mean Time To Repair-Specifies how long the system is allowed to be out of ordetJol-
lowing a failure
Time-to-prototype : A measure of the time required to prototype a design -
Product life-cycle (PLC) : The representation of the different stages of a product from its conception to disposal
Product life cycle curve : The graphical representation• ofI
the unit cost, product sales and profit
•
with respect to the
various life cycle stages of the product starting from conception to disposal
 Introduction to Embedded Systems

Objective Questions
l. Embedded systems are application and domain specific. State True or False
(a) True (b) False
2. Which of the following is true about Embedded Systems?
~
(a) Reactive and Real Time_ (b) Distributed (c) Operates in harsh environment
(d) All of these (e) None of these
3. Which of the following is a distributed embedded system?
(a) Cell phone (b) Notebook Computer (c) SCADA system (d) All of these
I
(e) None of these f
4. Quality attributes of an embedded system are
(a) Functional requirements
(c) Both
5. Response is a measure of
(a) Quickness of the system
(b) Non-functional requirements
(d) None of these

(b) How fast the system tracks changes in Input

II
(c) Bqth (d) None of these
/

6. Throughput of an embedded syst~m is a measure of f

(a) The efficiency of the system
(c) Both
7. Benchmark is
(a) A reference point
(b) The output over a stated period of time
(d) None of these

(b) A set of perfonnance criteria

I
(c) (a)or (b) (d) None of these
8. Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) defines the reliability of an embedded
system. State True or False
(a) True (b) False
9. MTBF gives the frequency of failures of an embedded system. State True or False
(a) True (b) False
10. Which of the following is true about the quality attribute 'maintainability'?
(a) The corrective maintainability requirement for a highly reliable embedded system is very less
(b) Availability of an embedded system is directly related to the maintainability of the system
(c) Both of these
(d) None of these ,
11. The Mean Time Between Failure (MTBF) for an embedded product is very high. This means:
(a) The product is highly reliable
(b) The availability of the product is very high
(c) The preventive maintenance requirement for the product is very less
(d) Allofthese
(e) None of these
12. The Mean Time Between Failure (MTBF) of an embedded product is 4 months and the Mean Time To Repair
J(MTTR) of the product is 2 weeks, What is the availability of the product?
(a) 100% (b) 50% (c) 89% (d) 10%
13. Which of the following are the three measures of infonnation security in embedded systems?
(a) Confidentiality, secrecy, integrity (b) Confidentiality, integrity, availability
(c) Confidentiality, transparency, availability (d) Integrity, transparency, availability
 Characteristics and Quality Attributes of Embedded Systems

14. You are working on a mission critical embedded system development project for a client and the client and your
company has signed a Non Disclosure Agreement (NOA) on the disclosure of the project-related information. You
share the details of the project you are working with your friend. Which aspect of Information security you are
violating here?
(a) Integrity (b) Confidentiality (c) Availability (d) None of these
15. Which of the following is an example of 'gradual' safety threat from an embedded system?
(a) Product blast due to overheating of the battery (b) UV emission from the embedded product
(c) Both of these (d) None of these
16. Non operational quality attributes are
(a) Non-functional requirements . (b) Functional requirements
(c) Quality attributes for an offline product (d) (a) and (c)
(e) None of these· .
17. Which of the following is (are) an operational quality attribute?
(a) Testability (b) Safety (c) Debug-ability (d) Portabilit):
(e) All of these
18. Which of the following is (are) non-operational quality attribute?
(a) Reliability (b) Safety (c) Maintainability (d) Portability
(e) All of these (t) None of these
19. In the Information security context, Confidentiality deals with the protection of data and application from unautho-
rised disclosure. State True or False ·
(a) True (b) False
20. What are the two different aspects of debug-ability in the embedded system development context?
(a) Hardware & Firmware debug-ability (b) Firmware & Software debug-ability
(c) None of these
21. For an embedded system, the quality attribute 'Evolvability' refers to
(a) The upgradability of the product (b) The modifiability of the product
(c) Both of these (d) None of these
22. Portability is a measure of 'system independence'. State True or False
(a) True (b) False
23. For a commercial embedded product the unit cost is high during
(a) Product launching (b) Product maturity
(c) Product growth ( d) Product discontinuing
24. For a commercial embedded product the sales volume. is high during
(a) Product launching (b) Product maturity
(c) Product growth (d) Product discontinuing

Review Questions
. l. Explain the different characteristics of embedded systems in detail.
2. Explain quality attribute in the embedded system development context? What are the different Quality attributes
to be considered in an embedded system design.
3. What is operational quality attribute? Explain the important operational quality attributes to be considered in any
embedded system design.
4. What is non~operational quality attribute? Explain the important non-operational quality attributes to be consid-
ered in any embedded system design.
5. Explain the quality attribute Response in the embedded system design context.
6. Explain the quality attribute Throughput in the embedded system design context.
 I
f
r

Introduction to Embedded Systems

7. Explain the quality attribute Reliability in the embedded system design context.
8. Explain the quality attribute Maintainability in the embedded system design context.
9. The availability of an embedded product is 90%. The Mean Time Between Failure (MTBF) of the product is 30
days. What is the Mean Time To Repair (MTTR) in days/hours for the product?
10. Explain the quality attribute Information Security in the embedded system design context.
11. Explain the quality attribute Safety in the embedded system design context.
, .
12. E.xplain the significance of the quality attributes Testability and Debug-ability in the_ embedded system design
context
13. Explain the quality attribute Portability in the embedded system design context.
14. Explain Time-to-market? What is its significance iff product development?
15. Explain Time-to-prototype? What is its significance in product development?
16. Explain the Product Life-cycle curve of an embedded product developme!!t.
I

As mentioned in the previous chapter on the characteristics _of embedded systems, embedded systems
are application and domain specific, meaning; they are specifically built for certain applications in cer-
tain domains like consumer electronics, telecom, automotive, industrial control, etc. In general purpose
computing, it is possible to replace a system with another system which is closely matching with the
existing system, whereas it is not the case with embedded systems. Embedded systems are highly spe-
cialised in functioning and are dedicated for a specific application. Hence it is not possible to replace
an embedded system developed for a specific application in a specific domain with another embedded
system design~d for some other application in some other domain. The following sections are intended
rI: to give the readers some idea on the application and domain specific characteristics of embedded
t systems.

t
r
,4.1 Wifi~.!!{G :J¥[AQHINE~APPLICATrlON~SPECIFIC EMBEDDED
SYSTEM
" ' :,,• ,.v•,~ •~

People experience the power of embedded systems and enjoy the features and comfort provided by
them, but they are totally unaware or ignorant of the intelligent embedded players working behind the
products providing enhanced features and comfort. Washing machine is a typical example of an embed-
ded system providing extensive support in home automation applications (Fig. 4.1 ).
 Introduction to Embedded Systems

As .mentioned in an earlier chapter, an embedded

system contains sensors, actuators, control unit and ap-
plication-specific user interfaces like keyboards, display
units, etc. You can see all these components in a washing
machine if you have a closer look atit. Some of them are
visible and some of them may be invisible to you.
The actuator part of the washing machine consists of
a motorised agitator, tumble tub, water drawing pump
and inlet valve to control the flow of water into the unit.
The sensor part consists of the water temperature sen-
sor, level sensor, etc. The control part contains a micro-
processor/controller based board with interfaces to the
sensors and actuators. The sensor data is fed back to the
control unit and the-control unit generates the necessary
actuator outputs. The control unit also provides connec-
tivity to user interfaces like keypad for setting the wash-
ing time, selecting the type of material to be washed
like light, medium, heavy duty, etc. User feedback is
reflected through the display unit and LEDs connected
to the control board. The functional block diagram of a
washing machine is shown in Fig. 4.2.

Integrated control User interface

panel with user
interfaee- LED display
!
Level sensor I
· Water
· inlet pipe
0 0
s 0
@88
0 0 0
88@
0 0 0
888
Keypad
Inner tub Body case
Temp Sensor

Outer tub . Water Outlet

Picture not to scale
( Fig. 4.2) Washing machine - Functional block diagram
l
t Embedded Systems-Application- and Domain-Specific

Washing machine comes in two models, namely, top loading and front loading machines. In top load-
ing models the agitator of the machine twists back and forth and pulls the cloth down to the bottom of
the tub. On reaching the bottom of the tub the clothes work their way back up to the top of the tub where
the agitator grabs them again and repeats the mechanism. In the front loading machines, the clothes are
tumbled and plunged into the water over and over again. This is the first phase of washing.
In the second phase of washing, water is pumped out from the tub and the inner tub uses centrifugal
force to wring out more water from the clothes by spinning at several hundred Rotations Per Minute
(RPM). This is called a 'Spin Phase'. If you look into the keyboard panel of your washing machine you
can see three buttons namely* Wash, Spin and Rinse. You can use these buttons to configure the washing
stages. As you can see from the picture, the inner tub of the machine contains a number of holes and
during the spin cycle the inner tub spins, and forces the water out through these holes to the stationary
outer tub from which it is drained off through the outlet pipe.
It is to be noted that the design of washing machines may vary from manufacturer to manufacturer,
but the general principle underlying in the working of the washing machine remains the same. The basic
controls consist of a timer, cycle selector mechanism, water temperature selector, load size selector and
start button. The mechanism includes the motor, transmission, clutch, pump, agitator, inner tub, outer
tub and water inlet valve. Water inlet valve connects to the water supply line using at home and regulates
the flow of water into the tub. ·
The integrated control panel consists of a microprocessor/controller based board with I/0 interfaces
and a control algorithm running in it. Input interface includes the keyboard which consists of wash type
selector namely* Wash, Spin and Rinse, cloth type selector namely* Light, Medium, Heavy duty and
washing time setting, etc. The output interface consists of LED/LCD displays, status indication LEDs,
etc. connected to the I/0 bus of the controller. It is to be noted that this interface may vary from manu-
facturer to manufacturer and model to model. The other types ofI/0 interfaces which are invisible to the
end user are different kinds of sensor interfaces, namely, water ternperature sensor, water level sensor,
etc. and actuator interface including motor control for agitator and tub movement control, inlet water
flow control, etc .

A.u1.10Mo-r1vi:-noM.l\ll'i:sPEc1F1c
. 4~2· EMBEDDED SYSTEM. Ei&iiv1Btlis oF
! . . . • . .· ., . • .· • ' : : ; ' : · • ••• •

The major application domains of embedded systems are consumer, industrial, automotive, telecom,
etc., of which telecom and automotive industry holds a big market share.
fI Figure 4.3 gives an overview of the various types of electronic control units employed iu automotive

l
applications.

4.2.1 InnerWorkings of Automotive Embedded Systems

Automotive embedded systems are the one where electronics take control over the mechanical systems.
The presence of automotive embedded system in a vehicle varies from simple mirror and wiper con-
trols to complex air bag controller and antilock brake systems (ABS). Automotive embedded systems
are normally built around microcontrollers or DSPs or a hybrid of the two and are generally known as
Electronic Control Units (ECUs). The number of embedded controllers in an ordinary vehicle varies

*Name may vary depending on the manufacturer.

I
 I
!
Introduction to Embedded Systems

13. Airbag control

12 Seat control

1. Instrumentation

2. Engine control
:-0
(J
(1)
t:l
R"
e:..
ir
(1)
0.
0
()
:,;-
s·
oc;
l

7. Wiper control
5. Headlamp control
6. ABS control
'c 4. Fuel injection control

~) :~~~~~ee',~t~J~~ i~:~~~:~~t~~,<>!i~~ ~()~~i,!1,:J, ,. ' '

(Ph.otor:;'tjiiiteft o,tHo~da SielCat/nd{a (wivw.Jionaac:arindfa.coin))

from 20 to 40 whereas a luxury vehicle like Mercedes Sand BMW 7 may contain 75 to 100 numbers of
embedded controllers. Government regulations on fuel economy, environmental factors and emission
standards and increasing customer demands on safety, comfort and infotainment forces the automotive
manufactures to opt for sophisticated embedded control units within the vehicle. The first embedded
system used in automotive application was the microprocessor based fuel injection system introduced
by Volkswagen 1600 in 1968. .
The various types of electronic'control units (ECUs) used in the automotive embedded industry can
be broadly classified into two-High-speed embedded control units and Low-speed embedded control
units.
4.2.1.1 High-speed Electronic Control Units (HECUs) High-speed electronic control units
(HECUs) are deployed in critical control units requiring fast response. They include fuel injection
systems, antilock brake systems, engine control, electronic throttle, steering controls, transmission
control unit and central control unit.
4.2.1.2 Low-speed Electronic Control Units (LECUs) Low-Speed Electronic Control
Units (LECUs) are deployed in applications where response time is not so critical. They generally
are built around low cost microprocessors/microcontrollers and digital signal processors. Audio con-
trollers, passenger and driver door locks, door glass controls (power windows), wiper control, mirror
control, seat control systems, head lamp and tail lamp controls, sun rnof control unit etc. are examples
ofLECUs.
l Embedded Systems-Application- and Domain-Specific

4:.2.2 Automotive Communication Buses

Automotive applications make use of serial buses for communication, which greatly reduces the amount
of wiring require,d inside a vehicle. The following section will give you an overview of the different
types of serial interface buses deployed in automotive embedded applications.
4.2.2.1 Controller Area Network (CAN) The CAN bus was originally proposed by Robert Bosch,
pioneer in the Automotive embedded solution providers. It supports medium speed (ISO 11519-class B
with data rates up to 125 Kbps) and high speed (ISO11898 class C with data rates up to lMbps) data
transfer. CAN is an event-driven protocol interface with.support for error handling in data transmission.
It is generally emplqyed in-safety system like airbag control; power train systems like engine control and
Antilock Brake System (ABS}; and navigation systems like GPS. The protocol format and interface ap-
plication development for CAN.bus will be explained in detail in another volume of this book series .
. 4.2.2.2 Local lnt~rconnect Network (LIN) LIN bus is a single mast~r multiple slave (up to 16
! independent slave nodes) communication interface. LIN is a low speed, single wire communication
interface with support for data rates up to 20 Kbps and is used for sensor/actuator interfacing. LIN bus
follows the master communication triggering technique to eliminate the possible bus arbitration prob-
lem that can occur by the simultaneous talking of different slave nodes connected to a single interface
bus. LIN bus is employed in applications like mirror controls, fan controls, seat positioning controls,
window controls, and position controls where response time is not a critical issue:
4.2.2.3 Media-Oriented System Transport (MPST) Bus The Media-oriented system transport
(MOST) is targeted for antomotive audio/video equipment interfacing, used primarily in European cars.
A MOST bus is a multimedia fibre-optic point-to-point network implemented in a star, ring or daisy-
chained topology over optical fibre cables. The MOST bus-Specifications define the physical (electrical
and optical parameters) layer· as well as the application layer, network layer, and media access control.
MOST bus is an optical fibre cable connected between the Electrical Optical Converter (EOC) and
Optical Electrical Converter (OEC), which would translate into the optical cable MOST bus.

4.2.3 Key Players of the Automotive Embedded Market

The key players of the automotive embedded market can be visualised in three verticals namely, silicon
providers, solution providers and tools and platform providers.

I 4.2. 3.1 Silicon Providers Silicon providers are responsible for providing the necessary chips which
are used in the control application development. The chip may be a standard product like microcon-
troller or DSP or ADC/DAC chips. Some applications may require specific chips and they are manufac-
tured as Application Specific Integrated Chip (ASIC). The leading silicon providers in the automotive
industry are:
Analog Devices (www.analog.com): Provider of world class digital signal processing chips, precision
analog microcontrollers, programmable inclinometer/accelerometer, LED drivers, etc. for automotive
signal processing applications, driver assistance systems, audio system, GPS/Navigation system, etc.
Xilinx (www.xilinx.com): Supplier of high performance FPGAs, CPLDs and automotive specific IP
cores for GPS navigation systyms, driver information systems, distance control, collision avoidance,
rear1 seat entertainment, adaptive cruise control, voice recognition, etc.

I
 Introduction to Embedded Systems

Atmel (www.atmel.com): Supplier of cost-effective high-density Flash controllers and memories. At-
mel provides a series of high performance microcontrollers, namely, ARM@ 1, AVR®2, and 80C:S 1. A
wide range of Application Specific Standard Products (ASSPs) for chassis, body electronics, security,
safety and car infotainment and automotive networking products for CAN, LIN and FlexRay are also
supplied by Atmel.
Maxim/Dallas (www.maxim-ic.com): Supplier of world class analog, digital and mixed signal products
(Microcontrollers, ADC/DAC, a·mplifiers, comparators, regulators, etc), RF components, etc. for all
kinds of automotive solutions.
NXP semiconductor (www.nxp.com): Supplier of 8/16/32 Flash microcontrollers.
Renesas (www.renesas.com): Provider of high speed microcontrollers and Large Scale Integration (LSI)
technology for car navigation systems accommodating three transfer speeds: high, mediqm and low.
Texas Instruments (www.ti.com): Supplier of microcontrollers, digital signal proces~ors and automo-
tive communication control chips for Local Inter Connect (LIN) bus products. .,,.
Fujitsu (www.fmal.fujitsu.com): Supplier of fingerprint sensors for security applications, graphic dis-
play controller for instrumentation application, AGPS/GPS for vehicle navigation system and different
types of microcontrollers for automotive control' applications.
Infineon (www.infineon.com): Supplier of high performance microcontrollers and customised applica-
tion specific chips.
NEC (www.nec.co.jp ): Provider of high performance microcontrollers.
There are lots of other silicon manufactures which provides various automo!ive support systems like
power supply, sensors/actuators, optoelectronics, etc. Describing all of them is out of the scope of this
book. Readers are requested to use the Internet for finding more information on them.
4.2.3.2 Tools and Platform Providers Tools and platform providers are manufacturers and supp1i-
ers of various kinds of development tools and Real Time Embedded Operating Systems for developing
and debugging different control unit related applications. Tools fall into two categories, namely embed-
ded software application development tools and embedded hardware development tools. Sometimes the
silicon suppliers provide the development suite for application development using their chip. Some third
party suppliers may also provide development kits and libraries. Some of the leading suppliers of tools
and platforms in automotive embedded applications are listed below.
ENEA (www.enea.com): Enea Embedded Technology is the developer of the OSE Real-Time operat-
ing system. The OSE RTOS supports both CPU and DSP and has also been specially developed to sup-
port multi-core and fault-tolerant system development.
.
The Math Works (www.mathworks.com): It is the world's leading developer and supplier of technical
.

software. It offers a wide range of tools, consultancy and training for numeric computation, visualisa-
tion, modelling and simulation across many different industries. MathWork's breakthrough product is
MATLAB-a high-level programming language and environment for technical computation and numeri-
cal analysis. Together MATLAB, SIMULINK, Stateflow and Real-Time Workshop provide top quality
tools for data analysis, test & measurement, application development and deployment, image processing
and development of dynamic and reactive systems for DSP and control applications.

1 ARM~J is the registered trademark of ARM Holdings.

2 AYR® is the registered trademark of Atmel Corporation.
I Embedded Systems-Application- and Domain-Specific

Keil Software (www.keil.com): The Integrated Development Environment Keil Microvision from Keil
software is a powerful embedded software design tool for 8051 & C166 family of microcontrollers.
Lauterbach (http://www.lauterbach.com/): It is the world's number one supplier of debug tools, pro-
viding support for processors from multiple silicon vendors in the automotive market.
ARTiSA~ (www.artisansw.com): Is the leading supplier of collaborative modelling tools for require-
ment analysis, specification, design and development of complex applications.
Microsoft (www.microsoft.com): It is a platform provider for automotive embedded applications
Microsoft's WindowsCE is a powerful RTOS platform for automotive applications. Automotive features1
are included in the new WinCE Version for providing support for automotive application developers.
4.2.3.3 Solution Providers Solution providers supply OEM and complete solution for automotive
applications making use of the chips, platforms and different development tools. The major players of
this domain are listed below.
Bosch Automotive (www.boschindia.com): Bosch is providing complete automotive solution ranging
from body electronics, diesel engine control, gasoline engine control, powertrain systems, safety systems,
in-car navigation systems and infotainment systems.
DENSO Automotive (www.globaldensoproducts.com): Denso is an Original Equipment Manufacturer
(OEM) and solution provider for engine management, climate control, body electronics, driving control
& safety, hybrid vehicles, embedded infotainment and communications.
Infosys Technologies (www.infosys.com): Infosys is a solution provider for automotive embedded hard-
ware and software. Infosys provides the competitive edge in integrating technology change through cost-
effective solutions.
Delphi (www.delphi.com): Delphi is the complete solution provider for engine control, safety, infotain-
ment, etc., and OEM for spark plugs, bearings, etc.
... . . .and many more. The list is incomplete. Describing all providers is out of the scope of this book.

Summary
✓ Embedded systems designed for a particular application for a specific domain cannot be replaced with another
embedded system designed for another application for a different domain
✓ Consumer, industrial, automotive, telecom, etc. are the major application domains of embedded systems. Tele-
com and aµtomotive industry are the two segments holding a big market share of embedded systems
✓ Automotive embedded systems are normally built around microcontrollers or DSPs or a hybrid of the two and
are generally known as Electronic Control Units (ECUs)
✓ High speed Electronic Control Units (HECUs) are deployed in critical control units requiring fast response, like
fuel iajection systems, antilock brake system, etc. ,
✓ Low speed Electronic Control Units (LECUs) are deployed in applications where response time is not so critical.
They are generally builtaround low cost ~icropro_c~ssors/microcontrollers and digital signal processors. Audio
controllers, passenger and driver' door locks, door glass controls, etc., are examples for LECUs.
✓ Automodve applications use serial buses for communication. Controller Area Network (CAN); Local Intercon-
nect Network (LIN), Media Oriented System Transport (MOST) bus, etc. are the important automotive commu-
nication buses. ·
 Introduction to Embedded Systems

an;.ev~~t}rifrn seiia)prk~col ~t¢rf,Hf1Yii~~~~port. for error hal}dling. in datati:ansrntssiog. It fa . ~~~e!~'.

'' ;eaJri :S,afe. ' ~ril. like airl,'.ag cbntrol, pow:ertrain systems liKe ~ngi,n:e control and'MtiloGkrBrijke
,;; ,y ; '.'!"·':.e'·""'r' -i :_:-''1·

. , W:sfai~l(urJJq;Il,(,;to:d~petlaent'sl~vfnudesfc'
~~ttt1~:\~!§ffab?W~rti~¥PP9AJdr d~Ji, t~te~.i!j,

I
Objective Questions
1. In Automotive ~ystems, High-speed Electronic Control Units (HECUs) are deployed in
(a) ·Fuel injectipn systems (b) Antilock brake systems
(c) Power windo-i,,s (d) Wiper control (e) Only (a) and (b)
'
,f
i
!
2. In Automotive systems, Low speed electronic control units (LECUs) are deployed in
(a) Electronic throttle (b) Steering controls (c) Transmission control (d) Mirror control
3. The first embedded system used in automotive application is the microprocessor based fuel injection system intro-
duced by ~·-- in 1968
(a) BMW (b) Volkswagen 1600 (c) Benz E Class (d) KlA
4. CAN bus is an event driven protocol for communication. State True or False
(a) True (b) False
5. Which of the following serial bus is (are) used for communication in Automotive Embedded Applications?
(a) Controller Area Network (CAN) (b) Local Interconnect Network (LIN)
(c) Media Oriented System Transport (MOST) bus (d) All of these (e) None of these
6. Which of the following is true about LIN bus?
(a) Single master multiple slave interface (b) Low speed serial bus
(c) Used for sensor/actuator interfacing (d) All of these (e) None of these
 Embedded Systems-Application- and Domain-Specific

7. Which of the following is true about MOST bus?

(a) Used for automotive audio video system interfacing
(b) It is a fibre optic point-to-point network
(c) It is implemented in star, ring or daisy-chained topology
(d) All of these (e) None of these
8. Which of the following is (are) example( s) of Silicon providers for automotive applications?
(a) Maxim/Dallas (b) Analog Devices (c) Xilinx (d) ·Atmel
(e) All of these (t) None of these

1
- ~ Reiriew Questions ]
1. Explain the role of embedded systems in automotive domain.
2. Explain the different electronic control units (ECUs) used in automotive systems.
3. Explain the different communication buses used in automotive application.
4. Give an overview of the different market players of the automotive embedded applicatio~ domain.
 ~ LEARNING OBJECTIVES
", _<''.- ,- _ .· , /;_'_ •> .:_:\, ": •'• :;::,J-'_ .::.:-';\::··_ .;;:~_-/;:·_,? . :(-~---~i/\'j?:. :•·. ~~?>_\::·>·-··,:< : -_ ·'::., ,'.:':t_,<:;.,1_·-/\/~,:~_iij!~-?;:~\
1/ Undi:rstand tfie different fdctors that neef to be considerlif while.i~eled:ing' a: m'icrocoritroller for an itmbeddecf,r!
; 'desig~ ·.. . . .· ·. ' · .. ·.•·. · · ; ·;. :· ..· . . . · · . '.,:'; 1
.~;,Kh~'wWhy:?Qffe1 i~ihep9pµlarcljriiceifor Jow,cos.tfowpeiforrrm~2€ ~tnbedded ~ystein design
}l.tf... ·.th¢tf'io
·z;~f§Q2(:!7Jic;fo~qatr~llerfqrcf,}te'cture >;;·.,: ,:c: .• /: . ·.. , .·'····.
>t:
. !';•1~'
'.'.,1? .. J' .t~fir,jgn)also,j:the'8os1:infcroc6ntroUer z, · . . ....· ....
V, Y:Liarn'the pr6gFaf!1.{1J~~ory Hnd i~temalcfqtamemory orgqh[$Gtion:of B051
:i;.Jepmfhe}fa ;Datq'~ewory:accessard:~9n7f;lelirpMrJne. . . •: eLimpfemehtatjon]of8051 . . . • J
Jl·:{Mrn. :~Hout'. ·.·.. . nisatid11 oflower'i.28 6ytes RAM¼~ d(Jt einbry/upper 12B·byfes'RAM fO(SFWafra
•. ·J2~byMs~RAM jorlntemafo~ta rnemow (IRf!:1) . .· . . . .• . . . . . ..
✓ tearn .qbQ'~l:the cpq regist~rs an1:gen~ral p"rlrpose tegi~tf!rsgf'8Q51
,;, Learn ,abiutJhe Qsti[lqtor,'uhitand Jpe~d ;J]'execution &j~Q5{'.1' . . .
✓ Learn pbout the. different 1/0 pods, organisation of the poris)lhe internatimplementation of the poit pins,
differe;t registe~ associated with the ports and the operation of ports
✓ Learn about interrupts and its significance in -1:mbedded appl(cations .
✓ Learn about the Interrupt System of 8051, the interrupts supported by 8051, interrupt priorities, different registers
associated with configuring the foterrupts, Interrupt Service Routine and their vector address .
✓ Learn about the Timer/Counter units supported by 80,51 and configuring the Timer unit for Timer/Counter opera-
tion. Learn the different registers associated with timer units and the different modes of operations supported by
Timer/Counter units
✓ Learn about the Serial Port of the 8051, the different control, status and data registers associated with it
✓ Learn the different modes of operations supported by the Serial port and setting the baudrate for each mode
✓ learn about the Power-On Reset circuit implementation for 8051
✓ learn about the different power saving modes supported by 8051
✓ learn the difference between 8051 and 8052

A recent survey on the microcontroller industry reveals that 8bit microcontrollers account for more than
40% of the total sales in the microcontroller industry. Among the 8bit microcontrollers, the 8051 family
is the most popular, cost effective and versatile device offering extensive support in the embedded appli-
I Designing_Embedded Systems with 8bit Microcontrollers-8051

cation domain. Looking back to the history of microcontrollers you can find that the 8bit microcontroller
industry has travelled a lot from its first popular model 8031 AH built by Intel in 1977 to the advanced
8bit microcontroller built by Maxim/Dallas recently, which offers high performance 4 Clock, 75MHz
operation 8051 microcontroller core (Remember the original 8031 core was 12 Clock with support for
a maxim.um system clock of 6MHz, so a performance improvement of 3 times on the original version
in execution) with extensive support for networking by integrating 10/100 Ethernet MAC with IEEE
802.3 MMI, CAN bus for automotive application support, RS-232 C interface for legacy serial applica-
tions, SPI _serial interface for board level device inter connect, 1-wire interface for connecting to low
cost multi-drop sen~ors and actuators, and 16MB addressing space for code and data memory.

Selection of a microcontroller for any application depends on some design factors. A good designer
finalises his selection based on a comparative study of the design factors. The important factors to be
considered in the selection process of a microcontroller are listed below.

5 .1. 1 Feature Set

The important queries related to the feature set are: Does the microcontroller support all the peripherals
required by the application, say serial interface, parallel interface, etc.? Does it satisfy the general I/0
port requirements by the application? Does the controller support sufficient number of timers and coun-
ters? Does the cdntroller support built-in ADC/DAC hardware in case of signal processing applications?
Does the controller provide the required performance?

5. 1. 2 Speed of Operation
Speed of operation or performance of the controller is another important design factor. The number
of clocks required per instruction cycle and the maximum operating clock frequency supported by the
processor greatly affects the speed.of operation of the controller. The speed of operation of the controller
is usually expressed in terms of million. instructions per secorid (MIPS).

5.1.3 Code Memory Space

If the target processor/controller application is written in C or any other high level language, does the
controller support sufficient code memory space to hold the compiled hex code (In case of controllers
with internal code memory)?

5.1.4 Data Memory Space

Does the controller support sufficient internal data memory (on chip RAM) to hold run time variables
and data structures?

5.1.5 Development Support

Development support is another important factor for consideration.
I
It deals with-Does the controller
manufacture provide cost-effective development tools? Does the manufacture provide product samples
 Introduction to Embedded Systems
I
L
!
for prototyping and sample development stuffs to alleviate the development pains? Does the controller I
I.
support third party development tools? Does the manufacture provide technical support if necessary? rI
I.
5.1.6 Availability
Availability is another important factor that should be taken into account for the selection process. Since
the product is entirely dependent on the pontroller, the product development time and time to marke_t the
't
product solely depends on its availability. By technical terms it is referred to ·as Lead time. Lead time is
the time elapsed between the purchase order approval and the supply of the product.

5.1.7 Power Consumption

The power consumption of the controller should be minimal. It is a crucial factor since high power
requirement leads to bulky power supply designs. The high power dissipation also demands for cool-
ing fans and it will make the overall system messy and expensive. Controllers should support idle and
power down modes of operation to reduce power consumption.

5.1.8 Cost
Last but not least, cost is a big deciding factor in selecting a controller. The cost should be within the
reachable limit of the end user and the targeted user should not be high tech. Remember the ultimate aim
of a product is to gain marginal benefit.

8051 is a very versatile microcontroller featuring powerful Boolean processor which supports bit manip-
ulation instructions for real time industrial control applications. The standard 8051 architecture supports
6 interrupts (2 external interrupts, 2 timer interrupts and 2 serial interrupts), two 16bit timers/counters,
32 I/O lines and a programmable full duplex serial interface. Another fascinating feature of 8051 is the
way it handles interrupts. The interrupts have two priority levels and each interrupt is allocated fixed 8
bytes of code memory. This approach is very efficient in real time application. Though 8051 is invented
·by Intel, today it is available in the market from more than 20 vendors and with more than 100 variants
· of the original 8051 flavour, supporting CAN, USB, SPI and TCP/IP interfaces, integrated ADC/DAC,
LCD Controller and exten4ed number of I/O ports. Another remarkable feature of 8051 is its low cost.
The 8051 fl.ash microcontroller (AT89C51) from Atmel is available in the market for less than 1US$ per
piece. So imagine its cost for high volume purchases.

5.3.1 The 8051 Architecture

The basic 8051 architecture consist of an 8bit CPU with Boolean processing capability, oscillator driver
unit, 4K bytes of on-chip program memory, 128 bytes of internal data memory, 128 bytes of special
function register memory area, 32 general purpose I/O lines organised into four 8bit bi-directional ports,
two 16bit timer units and a full duplex programmable UART for serial data transmission with configu-
rable baudrates. Figure 5.1 illustrates the basic 8051 architecture.
 Designing Embedded Systems with 8bit Microcontrollers-8051

PO.Oto P0.7 P2.0 toP2.7

Serial
(TI, RI)
Internal circuitry
Timer l

Timer External
incremerit

PSEN\
ALFJPROG\
EA\NPP
RST
RD\
WR\

Pl.OtoPl.7 P3.0toP3.7

5.3.2 The Memory Organisation

8051 is built around the Harvard processor architecture. The program and data memory of 8051 is
logically separated and they physically reside separately. Separate address spaces are assigned for data
memory and program memory. 8051's address bus is 16bit wide and it can address up to 64KB (2 16 )
r memory.

l 5.3.2.1 The Program (Code) Memory The basic 8051 architecture provides lowest 4K bytes
of program memory as on-chip memory (built-in chip memory). In 8031, the ROMless counterpart of
805 I, all program memory is external to the chip. Switching between the internal program memory and
external program memory is accomplished by changing the logic level of the pin External Access (EA\).
Tying EA\ pin to logic 1 (Vcd, configures the chip to execute instructions from program memory up to
4K (program memory location up to 0FFFH) from internal memory and 4K (program memory location
from 1000H) onwards from ext~rnalmemory, while connecting EA\ pin to logicO'(GND) configures the
chip to external program execution mode, where the entire code memory"is executed from the external
memory. Remember External Access pin is an active low pin (Normally referred as EA\). The control
signal for external program memory execution is PSEN\ (Program Strobe Enable). For internal program
 Introduction to Embedded Systems

memory fetches PSEN\ is not actjvated. For 8031 controller without on-chip memory, the PSEN\ signal
is always activated during program mem01y execution. The External Access pin (EA\) configuration
and the corresponding code memory access are illustrated in Fig. 5.2.
FFFFH' FFFFH

1000H
OFFFH

OOOOH OOOOH

EA\==O EA\== 1
, External program Internal program
memory access memory access

( Fig. 5.2) 8051 P~~gr,am memory organisation

If the program memory is external, 16 I/0 lines are used for accessing the external memory. Port 0
and Port 2 are used for external memory accessing. Port 0 serves as multiplexed address/data bus for
external program memory access. Similar to the 8085 microprocessor, Port 0 emits the lower order
address first. This can be latched to an 8bit external latch with the Address Latch Enable (ALE) signal
emitted by 8051. Once the address outin'.g is over, Port 0 functions as input port for data transfer from
the corresponding memory location. Th,e address from which the program instruction to be fetched is
supplied by the 16bit register, Program Counter (PC), which is part of the CPU. The Program Counter is
a 16bit register made up of two 8bit registers. The lower order byte of program counter register is held
by the PCL register and higher order by the PCH register. PCL and PCH in combination serve as a 16bit
register. During external program memory fetching, Port 0 emits the contents of PCL and Port 2 emits
the contents of PCH register. Port 0 emits the contents of PCL only for a fixed duration allowing .the
external latch to hold the content on arrival of the ALE signal. Afterwards Port 0 goes into high imped-
ance state, waiting for the arrival of data from the corresponding memory location of external memory.
Whereas Port 2 contin;ues emitting the contents of PCH register throughout the external memory fetch.
Once the PSEN\ signal is active, data from the program memory is clocked into Port 0. Remember, dur-
ing external program memory access Port 0 and Port 2 are dedicated for it and cannot be used as general
purpose ilo ports. The interfacing of an external program memory chip is illustrated in Fig. 5.3.
5.3.2.2 The Data Memory The basic 8051 architecture supports 128 bytes of internal data memory
and 128 bytes of Special Function Register memory. Special Functiqn Register memory is not avail-
able for the user for general data memory applications. The address range for internal user data memory
is OOH to 7FH. Special Function Registers are residing at memory area 80H to FFH. 8051 supports
interface for 64 Kbytes of external data memory. The control signals used for external data memory
 Designing Embedded Systems with 8bit Microcontrollers-80S1

Data Bus DO ....D7

Address Bus
Output enable of ROM chip

access are RD\ and WR\ and the 16bit register holding the address of external data memory address to
be accessed is Data Pointer (DPTR). Similar to the Program Counter, the Data Pointer is also made up
of two 8bit registers, namely, DPL (holding the lower order 8bit) and DPH (holding the higher order
8bit). The program counter is not accessible to the user whereas DPTR is accessible to the user and the
contents ofDPTR register can be modified. In external data memory operations, Port Oemits the content
ofDPL and Port 2 emits-the content of DPH. Port Ois address/data multiplexed in external data memory
operations also. The internal and external data memory model of 8051 is diagrammatically represented
in Fig. 5.4.

FFFFH
On-chip RAM
r~---,--:-
FFH i ·
l
I
I
\
!
I
I
I
I
I
Ii 80H '--,-'----

l 7FH
[
tt
I OOH

~ Data memory map for 8051

Internal data memory addresses are always one byte long. So it can accommodate up to 256 bytes
of internal data memory (Ranging from Oto 255). However the addressing techniques used in 8051
1
can accommodate 384 bytes using a simple memory addressing technique. The technique is: Direct
 Introduction to Embedded Systems

addressing of data memory greater than 7FH will access one memory space, namely Special Function
Register memory and indirect addressing of memory address greater than 7FH will access another
memory space, the upper 128 bytes of data memory (Direct and indirect memory addressing will be dis-
cussed in detail in a later section). Remember these techniques will work only if the upper data memory
is physically implemented in the chip. The basic version of 8051 does not implement the upper data
memory physically. However the 8052 family im,plements the upper data memory physically in the chip
and so the upper 128 byte memory is also available· for the user as general purpose memory, if accessed
through indirect addressing.
External data memory address can be either one or two bytes long. As described earlier, Port Oemits
the lower order 8bit address and, if the memory address is two bytes and if it ranges up to 64K, the entire
bits of Port 2 is used for holding the higher order value of data memory address. If the memory range
is 32K, only 7 bits of Port 2 is required for addressing the memory. For 16K, only 6 lines of Port 2 are
required for interfacing and so on. Thereby you can save some port pins of Port 2. The interfacing of an
external data memory chip is illustrated Fig. 5.5. ·

Data bus DO ....D7

Higher order address bus

( Fig. 5.5) External Data memory access

S.3.2.3 Paged Data Memory Access In paged mode addressing, the memory is arranged like the
lines of a notebook. The notebook may contain l 00 to 200 pages and each page may contain a fixed
number of lines. You can access a specific line by knowing its page number and the line number. Mem-
ory can also arrange like the lines of a notebook. By using 8bit address, memory up to 256 bytes can be
accessed. Imagine the situation where the memory is stacked of 256 bytes each. You can use port pins
(High order address rule) to signal the page number and the lower order 8 bits to indicate the mem01y
location corresponding to that page.
For example, take the case where paging is done using the port pin P2.0 and port Ois used for holding
the lower address. The memory range will be
 Designing Embedded Systems with 8bit Microcontrollers-80S1

S.3.2.4 The Von-Neumann Memory Model for 8051 The code memory and data memory of
8051 can be combined together to give the Von-Neumann architectural benefit for 8051. A single mem-
ory chip with read/write option can be used for this. The program memory can be allocated to the lower
memory space starting from 0O0OH and data memory can be assigned to some otner specific area after
the code memory. For program memory fetching and data memory read operations combine the PSEN\
and RD\ signals using an AND gate and connect it to the Output Enable (OE\) signal of the memory
chip as shown in Fig. 5.6.

Data bus DO .... D7

The Von-Neumann memory model is very helpful in evaluation boards for the controller, which
allows modification of code memory on the fly. The major drawbacks of using a single chip for program
and data memory are
• Accidental corruption of program memory
• Reduction in total memory space. In separate program and data memory model the total available
memory is 128KB (64KB program memory+ 64KB Data memory) whereas in the combined
model the total available memory is only 64KB
S.3.2.S Lower 128 Byte Internal Data Memory (RAM) Organisation This memory area is
volatile; meaning the contents of these locations are not retained on power lose. On power up these
memory locations contain r:andom data. The lowest 32 bytes of RAM (OOH to lFH) are grouped into 4
banks of 8 registers each. These registers are known as RO to R7 registers which are used as temporary
data storage registers during program execution. The effective usage of these registers reduces the code
memory requirement since register instructions are shorter than direct memory addressing instructions.
The next 16 bytes of RAM with address 20H to 2FH is a bit addressable memory area. It accommodates
128 bits (16 bytes x 8), which can be accessed by direct bit addressing. The address of bits ranges from
OOH to 7FH. This is very useful since 8051 is providing extensive support for Boolean operations (Bit
Manipulation Operations). Also it saves memory since flag variables c,an be set up with these bits and
 Introduction to Embedded Systems

there is no need to waste one full byte of memory for setting up a flag variable. These 16 bytes can also
be used as byte variables. The context in which these bytes are used as either byte variable or bit vari-
able is determined by the type of instruction. If the instruction is a bit manipulation instruction and the
operand is given as a direct address in the range OOH to 7FH, it is treated as a bit variable. The lower 128
bytes of internal RAM for 8051 family members is organised as shown in Fig. 5.7.

Scratchpad RAM
80 bytes 30H-7FH

Bit addressable area

(Bit addresses 00-07H)
16 bytes 20H-2FH
Bank3
Bank2 4 banks of 8 registers R0-R7
Bank 1 32 bytes 00H-lFH

Bank0

(Fig. 5.7) Int~r·naB~8 bytes oflower o~der data memory~~~~isa.Ho~

Remember the byte-wise storage and bitwise storage in the area 20H to 2FH shares a common physi- f
cal memory area and you cannot use this for both byte storage and bit storage simultaneously. If you do
so, depending on the usage, the byte variables and bit variables may get corrupted and it may produce
unpredicted results in your application. This is explained more precisely using the following table.

B4
7CH
74H
6CH
q4H
SCH
54H
AEH 4DH 4CH
44H
3CH
34H
2CH
24H
lCH
 l
I Designing Embedded Systems with 8bit Microcontrollers-BOSJ

BO, Bl, B3 ... B7 represents the bit addresses. Now let's have a look at the following piece of
Assembly code:

.·•.:

:·, ~· .,.";''""·•· ,· ,•~____ , ,. •·'·•·,::.~·-: ,.. :._ ..- .:'"<;... -:: -:, '-·"

This piece of assembly code sets the bit with b_it address 0lH and loads the memory location 20H
with value F0H. Don't worry about the different instructions used here. We will discuss about the 8051
instruction set in a later chapter. The MOV 20H, #OOH instruction clears the memory location 20H. The
SETB OJH instruction stores logic 1 in the bit address 0lH. In reality the bit address 0lH is the bit 1 of
the memory location pointed by address 20H. Executing the instruction SETB OJH changes the contents
of memory location 20H to 02H (0000001 Ob. Only bit 1 is in logic 1 state). The instruction MO V 20H,
#FOH alters the content of memory location 20H with F0H (11110000b ). This overwrites the informa-
tion held by bit address 0IH and leads to data corruption. So be careful while using bitwise storag~ and
byte-wise storage simultaneously.
The next 80 bytes of RAM with address space 30H to 7FH is used as general purpose scratch-
pad RAM. Though memory spaces OOH to 2FH have specific usage, they can also be used as general _
:) purpose scratchpad (Read/Write) RAM. The lower 128 byte RAM can be accessed by either direct
e addressing or indirect addressing.
5.3.2. 6 The Upper 128 bytes RAM (Special Function Registers) The upper 128 bytes of RAM
when accessed by direct addressing, accesses the Special Function Registers (SFRs). SFRs include port
latches, status and control bits, timer control and value registers, CPU registers, stack pointer, accumula-
tor, etc. Some of the SFR registers are only byte level accessible and some of them are both byte,.wise
and bit-wise accessible. SFRs with address ends in OH and 8H are both bit level and byte level acces-
sible. In the standard 8051 architecture, among the 128 bytes, only a few bytes are occupied by the SFR
and the rest are left unused and are reserved for future implementations. The table given below explains
l the SFR implementation for standard 8051 architecture.

I ·_- . '1:2::r.!r_~:!_}-_._r_---_",_~1'.};']1~:. }~i .-

.,, __ ;', ---

Port O
· ·;:.·<~ l f( :- :_: · ,\_ _~-
8AH
1
'~f;; -~, J ;-r}t:;};;~WJttr;~[l!,:, • ,,,,,,,11.-:·.-.

B
 Introduction to Embedded Systems

SFR memory is not available to the user for general purpose scratchpad RAM usage. However the
user can modify the contents of some of the SFR according to the program requirements. Some of the
SFRs are Read Only. Some of the SFR memory spaces are not implemented in the basic 8051 version.
They are reserved for future use and users are instructed not to do anything with this reserved SFR
space. Reading from the unimplemeated SFR memory address returns random data and writing to this
memory location will not produce any effect. Each of the SFRs will be discussed in detail in the sections
covering their usage.
5.3.2.7 Upper 128 Bytes of Scratchpad RAM (!RAM) Variants of 8051 and the 8052 architec-
ture where the upper 128 bytes of RAM are physically implemented in the chip can be used as general
purpose scratchpad RAM by indirect addressing. They are generally !mown as IRAM. The address of
IRAM ranges from 80H to FFH and the access is indirect. Registers RO and Rl are used for indirect ad-
dressing. For example, for accessing the IRAM located at address 80H, load RO or Rl with 80H and use
the indirect memory access instruction. The following piece of assembly code illustrates the same.
MOV . . ROi#~Qff;;:; 'Lfad' H~3¥1t~:~ctct~t,~f3;S?'~{.Hj?:;h. 1n~i1~c5;' r,r9'JiJi~;, ):' .
.MOV '. A,'@RO ./, .;'!LoadiACGUIT)Ul:a½Ol'.'·'YWl.'th .IRAM';tont::en;t:.: ·at;'ad(:j:fce&si}SOH .

5. 3. 3 Registers
Registers of 8051 can be broadly classified into CPU Registers and Scratchpad Registers.
5.3.3.1 CPU Registers Accumulator, B register, Program Status Word (PSW), Stack Pointer (SP),
Data Pointer (DPTR, Combination of DPL and DPH), and Program Counter (PC) constitute the CPU
registers. They are described in detail below.
Accumulator (ACC) (SFR-EOH) It is the most important CPU register which acts as the heart of all
CPU related Arithmetic operations. Accumulator is an implicit operand in most of the arithmetic opera-
tions. Accumulator is a bit addressable register.
ACC.7 · . · A<;}C.6.

B Register (SFR-FOH) It is a CPU register that acts as an operand in multiply and division operations.
It also stores the remainder in division and MSB in multiplication Instruction. B can also be used as a
general purpose register for programming.
Program Status Word (PSW) (SFR-DOH) It is an 8-bit, bit addressable Special Function register
signalling the status of accumulator related operations and register bank selector for the scratch pad
registers RO to R7. The bit details of PSW register is given below.
PSW.1 ·rsWiJ ?,i:r~w;s. :ftswi?, ·,;'. 'iij~~.,r·•/;::,;: P~i\2. :::~';r~~J,;"> :::::t~W:~<
i CY AC FO RSl RS0 OV P
The table given below explains the meaning and use of each bit.
Bit'::. ,,N,a,me', .>: J:J ,,\:{~;,, ~~i~[~ ,•, .-,1~t.~~,~~:'. ~: ::~t~d~~~£~/.i ,:~:\ :,!.e~f;~f~Ji~~J:;:~.~~;;;~~~ifjt{~~:il
i ..,, .. 1- '.'.>:.~ ....,;·}:.\~';("-.:....'\ -'f-: '. ··.~·-'-~---·<. t: <-~,:-
. ?. _.'<<ti ._ .. '·- <;:
CY Carry flag ' ..' ·-:,.-·•"; . ,·:~..:·· ,.. · r,~

Sets wh~O:: 1,1 ~i:ry 09cur~ i?,n tp:e\iJ.QQitjQn ·of ~9 .B~'bit.~uffibers or~eri.a;borrow
'Fr-,·' .• '_ ·:·.-.. 1•.~~'i,~-\.~~-·i'::r,,:;·r·~,f:J~>-·' ··:'-~·;,'..~

occur~:~~T~fwbtr~~ti~~oftwo.$~~itn~~e~§- .j:;3 ;i}~t<::- .· ( .· )',' :c, I,

i ~r? :. ?4~iliicy1in~;;~·?; ·
 Designing Embedded Systems with 8bit Microcontrollers-8051

The following table illustrates the possible combinations for the register bank select bits, the cor-
responding register bank number and the address for the scratchpad registers RO-R7 in the specified
register bank.

The power-on reset value for the bits RS 1 and RS2 are Oand the default register bank for scratchpad
registers RO to R7 is Oand the address range for RO to R7 is OOH to 07H. A programmer can change the
registeroank by changing the values of RS 1 and RS0. The following piece of assembly code illustrates
the selection of bank 2 for the scratchpad registers RO to R7.

·. ·.•.::;i~;j~j~a~iti~si~\an/:2.
l _Data Pointer (DPTR) (DPL: SFR-82H, DPH: SFR-83H) It is a combination of two 8-bit register
. namely DPL (Lower 8-bit holder of DPTR) and DPH (Higher order 8-bit holder ofJ:?PTR). DPTR holds
the 16-bit address of the external memory to be read or written in external data memory operations. DPH
r
j
and DPL can be used as two independent 8-bit general purpose registers for application programming.
Program Counter (PC) It is a 16-bit register holding the address of the code memory to be fetched.
It is an integral part of the CPU and it is hidden from the programmer (It is not accessible to the pro-
grammer).
Stack Pointer (SP) (SFR-81H) It is an 8-bit register holding the current address of stack memory.
Stack memory stores the program counter address, other memory and register values during a sub rou-
tine/function call. On power on reset the stack pointer register value is set as 07H. The stack pointer
address and bank 0, address of R7 is same when the controller is at reset, so care should be taken for
selecting SP address. It is the responsibility of the programmer to assign sufficient stack memory by
entering the starting address of stack into the Stack Pointer register. Care should be taken to avoid the
 Introduction to Embedded Systems

[
overflow of stacks and merging of stack memory with data memory. This will result in un-predicted
program flow. The stack grows up in memory. f
5.3.3.2 Scratchpad Registers (RO to R7) Thescratchpadregisters RO to R7 is located in the lower
32 bytes of internal RAM. It can be on one of the four banks, which is selected by the register selector
bits RS0 and RS I of the PSW register. On power on reset, by default, RS0 and RS 1 are 0 and the default
I
bank selected is bank 0. There are eight scratchpad registers and they are named as RO, RI ... R7. The
register names and their memory a~dress corresponding to bank 0 are given bdow.
I
As the bank number changes the register address also offsets by the memory address bank number
multiplied by 8. Though you can select between the register banks 0 and 3, there will be only one active
register bank at a time and it depends on the RS0 and RS 1 bits of Program Status Word (PSW). Reg-
isters RO to R7 are used as general purpose working registers. RO and RI also handle the role of index I
addressing or indirect addressing register (@RO and@Rl instructions). RO and RI can also be used for '
external memory access in place ofDPTR, if the memory address is 8-bit wideJ(MOVXA, @RO) will
be discussed later).

5.3.4 Oscillator Unit

The. program execution is dependent on the clock and the oscillator unit is responsible for generating
the clock signals. All 8051 family microcontrollers contain an on-chip oscillator. This contains all nec-
essary oscillator driving circuits. The only external component required is a ceramic crystal resonator.
The 8051 on chip oscillator circuit provides external interface option through two pins of the microcon-
troller, namely, XTAL 1 and XTAL2,.
If you are using a ceramic resonator, you can con-
nect it across the XTALl and XTAL2 pins of the chip
with two external capacitors. Capacitors with values
15pF, 22pF, 33pF, etc. are used with the crystal reso-
nator. This is the cheapest solution since the total cost
for a ceramic resonator and two capacitors is always
less than a standalone oscillator module.
If an external stand alone oscillator unit is used,
22 pF ·
Crystal TI
'

I
the output signal of the oscillator unit should be
~resonator
connected to the pin XTALl of the chip and the pin
XTAL2 should be left unconnected for a CMOS*
type microcontroller (80C51). For an NMOS** type ( Fig. 8.8) C~~uit c:onfiguratioi,. for -q.siJ:!g ,on-chip
micr~controller, the oscillator output signal should oscillator '
be connected to the Pin XTAL2 and the pin XTALl
should be grounded (Fig. 5.8).

• CMOS-Complementary metal-oxide-semiconductor field effect transistor technology for digital circuit design. CMOS features less
power consumption and high logic density on an integrated circuit. ;
·• NMOS-n-type metal-oxide-semiconductor field effect transistor technology for digital circuit design. It is an old technology and pos-
sesses the drawback of noise susceptibility and slow logic transition. In modem designs it is suppl&t1ted by CMOS technology.
 Designing Embedded Systems with 8bit Microcontrollers-8051

You may be thinking why an oscillator circuit is required? The answer is-The microcontroller chip
is made up of digital combinational and sequential circuits and they require a clock to drive the digital
circuitry. The clock is supplied by this oscillator circuit and the operational speed of the chip is depen-
dent on the clock speed.
5.3.4.1 Execution Speed The execution speed of the processor is directly proportional to the oscil-
lator c~ock frequency. Increasing the clock speed will haye direct impact on ~he speed of program execu-
tion. But the internal processor core design will always have certain limitations on the maximum clock
I '
frequency on which it cah be operated. During program execution the instructions stored in the code
memory is fetched, decoded and corresponding action is initiated. Ertch instruction fetching consists of
the number of machine cycles. The instruction set of 8051 contains single cycle to four machine cycle
instructions.
Each machine cycle is made up of a sequence of states called T states. The original 8051 processor's
machine cycle consists of 6 T states and is named Sl, S2, S3 ... S6. Each T states in tum consist of two
oscillator periods (Clock cycles) and so one m~chine cyde contains 12 clock cycles. For a one machine
cycle instruction to execute, it takes 12 clock cycles. If the system clock frequency is 12MHz, it takes
lmicrosecond (lµs) time to execute one machine cycle. The machine cycle, T state and clock cycle
relationship is illustrated in the following Fig. 5.9.

◄ SlPl 111-◄ S 1P2 II-◄ S2Pl 11-◄ S2P2 --◄'S3Pl 111-◄ S3P2 II-◄ S4Pl 111-◄ S4 P211-◄ S5Plll-◄ S5P2►◄ S6Pl ►◄ S6P2 ►

( fig. 5.9) Machine Cycles, T state & clock periods

I 5.3.5 Port
Port is, a group of Input/Output (I/0) lines. Each port has its own port control unit, port driver and buf-
fers. The o'rigitial version of 8051 supports 32 'I/0 lines grouped into 4 l/0 ports, consisting of 8 I/0
lines pe;r port. The ports are nathed as Port 0, Port I, Port 2 and Port 3. One output driver and one input
,
1
buffer is asso'ciated ;Vith e~ch l/0 li~e. All four ports are bi-directional and an 8bit latch (Special Func-
tion Register) is associated with each pop:. ,
1~.3.,Stl1 Port O PORT 0 is.~ bi-directionaLport,' which is used as a multiplexed address/data bus in
extemaLdata memor;y/program memory operations: Port Opin'organisatio.n is illustrated in Fig. 5.10.
E~ch pin of Port 0 poss,esses a bit ,latch which is part of the Special Function Register (SFR) for Port
0, PO. The latch is a D flip flop and tt,clocks in a logic value (either logic 1 or logic 0) from the internal
 Introduction to Embedded Systems

Internal bus
Address/ Vee
data Read pin
I'
t
Read latch Control
I
t
I

Write to PO.x pin. I

latch (x=0,1, .... 7)
I
bus when a write to the corresponding latch signal is issued by the internal control unit. Apart from the
I
t

write to latch operation you can read the contents of the corresponding Port OPin latch by activating a
Read Latch signal. The Read Latch signal is asserted on executing an instruction with a read from the
corresponding 'port latch' instruction (e.g. ANL PO, A reads the PO latch, logical AND it with accumula-
tor and loads the latch with the result. Similarly, the instruction MOV PO.O,C reads the Port Obyte (8
bits of the PO latch) and modify bit Oand write the new byte back to the PO latch. In summary all 'Read-
Modify-Write' instructions generate Read Latch control signal).
The Read Pin control signal enables reading the status of a port pin. The Read Latch and f?-ead Pin
operations act on two different ways. Read Latch reads the content of corresponding port's SFR/SFR bit
latch whereas Read Pin reads the present state of the corresponding port pin. .

I
Port Ois designed in a way to operate in different modes. It acts as an 1/0 port in normal mode-of
operation and as a multiplexed address data bus in external data memory/program memory operations.
If the program memory is external to the chip, Port Oemits the program counter low byte in external
program memory operation for specific time duration and then acts as an input port to fetch the instruc-
tion from the address specified by the program counter. In external data memory operations PO emits the
lower order byte of the DPTR Register (DPL).
I
If you look back to the Port 0 pin organisation, you can see that during-external memqry related
operations the multiplexer disconnects the port Obit output line from its corresponding bit latch and
directly connect it to the ADDRESS/DATA line and the output driver circuitry is driven according to the
ADDRESS/DATA line and the control. .
The output drivers of Port 0 are formed by two FETs, out of which the top FET functions as the in-
ternal port pull-up. The pull-up FET driver for Port 0 is active only when the address line is emitting ls
during external memory operations. The pull-up FET will be off on all other conditions and the Port 0
pins which are used as output pins will become open drain (Open Collector for TTL logic). On writing
a 1 to the corresponding port bit SFR latch, the bottom FET is turned off and the pin floats and ~ti enters
in a high impedance state. ·
In order to make any Port Opin an input pin, a logic 1 should be written to the corresponding Port
0 SFR latch bit and an external pull-up resistor (in the range of Kilo ohms, typic~.lly 4.7K) should be
connected across the corresponding Port Opin and power supply Vee' which will abt as a bypass to the
internal pull-up FET. ·
If Port Ois used for external memory or device interfacing; it should be equipped with external pull-
up resistors to provide noise immunity to Port Odata lines.
 Designing Embedded Systems with 8bit Microcontrollers-8051

When configured as 0/p port by writing ls to the Port OSFR, all Port Opins floats and it is said to be
in a high impedance state. Port Ois a true bi-directional port.
Port OSFR (PO) (SFR-BOH) Port OSFR is a bit addressable Special Function Register that acts as the
bit latch for each Port Opins.

During external memory operations PO SFR gets 1s written into it. The reset value of Port OSFR is FFH
(All latch bits set to 1)
5.3.5.2 Port I PORT 1 is a bi-directional port which is used as a general purpose I/0 port. The Port
1 pin organisation is given in Fig. 5.11.

Internal bus

Pl.x pin
(x == 0,1, .... 7)

As seen in the pin organisation, Port 1 pin contains an internal pull-up resistor. In order to make the
Port 1 pins as input line, the corresponding SFR latch bit for Port 1 should be kept as 1. Writing a 1
into any of the Pl SFR bit latch turns off the output driver FET and produces logic high at the corre-
sponding port pin. The internal pull up for Port 1is fixed and weak. ·When Port 1 pins are configured· as
inputs (by writing a 1 to the corresponding Port 1 SFR bit latch) the pins are pulled high and the:y can
1
source current when an externally connected device pulls the port pin to low, signaling a logic Oat the
- corresponding input line and places logic Oto the internal bus in response to a Read Pin command. If
t the externally connected device forces logic high, the Read Pin .control signal generated by a Read Pin

I related command (e.g. MOV A,Pl, MOV C,Pl.O, etc.) places logic high into the internal bus.
Since Port 1 holds fixed internal pull ups and are capable of sourcing current, it is known as Quasi
Bi-directional.
t P-ort 1 SFR (Pl) (SFR- 90H) It is also a bit addressable Special Function Register that acts as the bit
latch for each pin of Port L The bit details of Portl SFR is given below.

The reset value of Port 1 SFR is FFH (All bit latches set to 1).
 Introduction to Embedded Systems

5.3.5.3 Port 2 Port 2 is designed to operate in two different modes. It acts as general purpose I/O
port in normal operational mode and acts as higher order address bus in external data memory/program
memory operations. Figure 5.12 illustrates the Port 2 pin organisation.

Internal bus

Control
Read pin
Address

P2.x Pin
(x = 0,1, .... 7)

Port 2 emits the higher order byte of external memory address if the address is 16 bits wide. A~ seen
in the figure, during 16-bit wide external memory operations the base drive for the O/p driver FET is
internally switched to the address line. If the address line is e~itting a 1, the O/p driver FET is turned
off and the logic 1 is reflected on the O/p pin. If the address line is emitting a 0, the O/p driver FET is
turned on and the logic 0 is reflected at the corresponding pin.
The content of Port 2 SFR remains unchanged during external memory access and it holds the pre-
vious content as such. It is_to-be noted that if Port 2 is in external memory operation it cannot be used
as general purpose I/O line. When not used for external memory access, Port 2 can be used as general
purpose I/O port. During normal operation mode, the internal multiplexer switches the base line (GATE)
of O/p FET to the D latch O/p of corresponding SFR bit l~tch. In normal operation mode when a 1 is
written into any of the P2 bit latch, the O/p driver FET is turned off and as in the case of Port I this line
acts as an I/p line. P2 is a Quasi bi-directional port.
· Port 2 SFR (P2) (SFR- JIOH) It is a bit addressable Special Function Register that acts as the bit latch
for each pins of Port 2. The reset value of Port 2 SFR is FFH (All bit latches set to 1).

5.3.5.4 Port 3 Port 3 is a general purpose I/O port which is also configurable for implementing alter-
native functions. Port 3 Pin configuration is shown in Fig. 5.13.
Port 3 is identical to Port I in operation. All the settings that need to be don~ for configuring Port 1
as I/O port is applicable to Port 3 also. The only difference is that the SFR l~tch for Port 3 is P3. Port 3
supports alternate I/O functions. The alternate I/O functions supported by Port'3 and the pins used for
these alternate functions are tabulated below. ;
 Designing Embedded Systems with 8bit Microcontrollers-8051

Internal bus

Read latch Vee

Alternate 0/p
function

Read pin Alternate 1/p function

It is obvious from the table that all 8 pins of Port 3 are having some alternate I/O function associ-
ated with them. From the Port 3 pin configuration it is clear that the alternate I/O functions will come
into action only if the corresponding SFR bit latch is set to logic 1. Otherwise the port pin remains at
logic 0.
Port 3 SFR (P3) (SFR-BOH) It is a bit addressable Special Function Register that acts as the bit latch
for each pin of Port 3. Reset value of Port 3 SFR is FFH (All bit latches set to 1). •

5.3.S.5 'Read Port Latch' and 'Read Port Pin' Operations As we discussed earlier, the 'Port
Read' operations fall into two categories namely, Read Latch and Read Pin. The Read Latch operation
reads the content of the corresponding port latch. The port architecture for all 4 ports contains neces-
sary circuit for reading the Port Latch for all port pins. The read Port Latch operation is triggered by
the control signal Read Latch. The Read Latch control signal is generated internally on executing an
instruction implementing the Read Latch operation. The Read-Modify-Write instructions which reads
the port, modifies it and re-writes it to the port, operates on the port latch instead of port pins. The fol-
l
Introduction to Embedded Systems

lowing Read-Modify-Write instructions operate on port latch when the destination operand is a Port or
a Port bit.
ANL Px, <source> (x= 0,1,2,3. e.g. ANL PO, A)
ORL Px, <source> (x= 0,1,2,3. e.g. ORLP 1, A)
XRL Px, <source> (x= 0,1,2,3. e.g. XRL P2, A)
JBC Px.y, LABEL (x= 0,1,2,3. y = 0 to 7 e.g. JBC P3.0, REPEAT)
CPL Px.y (x= 0,1,2,3. y = 0 to 7 e.g. CPL P0.2)
INC Px (x= 0,1,2,3. e.g. INC-PO)
DEC Px (x= 0,1,2,3. e.g. DEC Pl)
DJNZ Px, LABEL Px (x= 0,1,2,3. e.g. DJNZ PO, REPEAT)
MOV Px.y, C (x= 0, 1,2,3. y = 0 to 7 e.g. MOV P3. 7, C)
CLR Px.y (x= 0,1,2,3. y = 0 to 7 e.g. CLR P1.0)
SETB Px.y (x= 0,1,2,3. y = 0 to 7 e.g. SETB P3.6)
The instructions MOVPx.y, C, CLRPx.y and SETB.Px.y, read the Portx byte (8 bits of the Px latch)
and modify bit y and write the new byte,back to the Px latch.
The following assembly code snippet illustrates the Read Latch operation.

Executing the instruction MOV PO, #-OFH loads the P9rt 0 latch with 0FH (The latches for port pins
P0.0 to P0.3 are set). Now Port pins P0.0 to P0.3 acts ·as input pins. Executing the instruction MOVA,
#-OFH loads the accumulator with 0FH. The ANL PO, A instruction reads the PO latch and logical AND it
with accumulator and rewrites the PO latch with the ANDed result. The status of port pins configured as
input port has no effect on the instruction ANL PO, A. Suppose P0.0 pin (Not P0.0 latch bit) is at logic
0 and pins P0. l to P0.3 are at logic 1 at the time of executing the instruction ANL PO, A, still Port 0 latch
is loaded with 0FH and not 0EH.
The Read Pin operation reads the status of a port pin when the corresponding port pin is configured
as input pin (When the corresponding port latch bit is loaded with logic 1). The port architecture for all
4 ports contains necessary circuit for reading the Port Pin for all ports. The read Port Pin operation is
triggered by the control signal Read Pin. The Read Pin control signal is generated internally on execut-
ing an instruction implementing the Read Pin operation.MOVA, Px, MOV C, Px.y are examples for
Read Pin instructions. The following code snippet illustrates the 'Read Pin' operation.
MOV PO, #OFH. ; · Corrfigur~ .,po • 0. to PO\3 -plns as -input pin;s .
MOVA, PO ; Load Accumulator with PQ ~9rt,ilri dt~tu:s

Executing the instruction MOVf0, #0FHloads theJ;ort 0 latch with 0FH (The latches for port pins P0.0
to P0.3 are set). Now Port pins PO.Oto P0.3 act as inP,ut pins. Executing the instruction MOVA, PO loads
accumulator with the Pin status of pins P0.0 P0.3. Suppose P0.0 pin is at logic 0 and pins PO.I to P0.3
are at logic 1 at the time of executing the instruction MOVA, PO, the accumul.ator is loaded with 0EH.
S.3.S.6 Source and Sink Currents for 80S1 Ports
Source Current The term source current refers to how much current the 8051 port pin can supply to
drive an externally connected device. The device can be an LED, a buzzer or a TTL logic device. For TTL
family of 8051 devices the source current is defined in terms of TTL logic. TTL logic has two logic levels
 Designing Embedded Systems with 8bit Microcontrollers-8051

namely logic 1 (High) and logic O(Low). The typical voltage levels for logic Low and High is given in the
following table.

The logic levels are defined for a TTL gate acting as input·and output. For logic Othe input voltage
level is defined as any voltage below 0.8V and the current is l .6mA sinking current to ground through
a TTL input. According to the 8051 design reference, the maximum current that a port pin (For an LS
TIL logic based 8051 devices) can source is 60 µA. • ·
I

Sink Current It refers to the maximum current that the 8051 port pin can absorb through a device
which is connected to an external supply. The device can be an LED; a buzzer or a TTL logic device
(For TTL logic based 8051 devices). Pins of Ports Pl, P2 and P3 can sink a maximum current of 1.6
mA. Port Opins can sink currents up to 3.2 mA. Under steady state the maximum sink current is limited
by the criteria: Maximum Sink Current per port pin = 10 mA, Maximum Sink current per 8-bit port for
port O 26 mA, Maximum Sink Current per 8-bit port for port 1, 2, & 3 = 15 mA, Maximum total Sink
current for all output pin= 71 mA (As per the AT89C5 l Datasheet). Figure 5.14 illustrates the circuits
for source, sink and ideal port interfacing for 8051 port pins.
Vee
Vee
~
...,0
.;13
LED "'
LED <l)

~ ~

(a) (b)

(ti§: $.14) (a) Cui:rent'Sourci11g, (b) Currert!'Silildng (c) Ideal Port pin interface .for 805 I

Figure 5.14(a) illustrates the current sourcing for port pins. Since 8051 port pins are only capable
of sourcing less than 1 mA current, the brightness of LED will be very poor. Figure 5. l 4(b) illustrates
the current sinking for port' pins. In this configuration, the forward voltage of LED while conducting is
approximately 2V and the supply voltage 5V (Vcc) is distributed across the LED and the internal TTL
, circuitry. The extra 3V has to be dropped across the internal TTL circuitry and this will lead to high
power dissipation, which in tum will result in the damage of the LED or the port pin. This type of design
is not recommended in embedded design. Instead the current through the LED is limited by connecting
the LED to the power supply through a resistor as shown in Fig. 5.14(c). In this configuration, the port
pin should be at Logic Ofor the LED to conduct. For a 2.2V LED, the drop across Resistor is calculated
as Supply voltage - (LED Forward Voltage+ TTL Low Voltage)= 5 - (2.2 + 0.8) 2.0V. The Resis-
tance value is calculated as 2V / (Required LEO Current). Refer LED data sheet for LED current. If the
resistance value is not properly selected, i( may lead to the flow of high current through the LED and
may damage the LED.
 Introduction to Embedded Systems

-
Design an 8051 microcontroller based system for displaying the binary numbers from Oto 255 using 8 LEDs as per the
specifications given below:
1. Use Atmel's.AT89C51/52 or AT89S8252 (Flash microcontroller with In System Programming (ISP) support) for
designing the system.
2. Use a 12MHz crystal resonator for generating the necessary clock signal for the controller.
3. Use _on-chip program memory for storing the program instructions.
4. The 8LEDs are connected to't9,.e port pins P2.0 to P2.7 of the microcontroller and are arranged in a single row with
the 1-ED connected to P2.0 at the rightmost position (LSB) and the LED connected to P2.7 at the leftmost position
(MSB).
5. The LEDs are connected to the port pins through pull-up resistors of 470 ohms and will conduct only when the
corresponding po,rt pin is at logic 0.
6. Each LED represents the corresponding binary bit of a byte and it reflects the logic levels of the bit through turning
ON and OFF the LED (The LED is turned on when the bit is at logic 1 and off when the LED ii, at logic 0).
7. The counting starts from 0 (All LEDs at turned OFF state) and increments by one. The counter is incremented at
.I
the rate of 5 seconds.
8. When the counter is at 255 (0FFH, all LEDs are in the tum ON state), the next increment resets the counter to OOH
and the counting process is repeated.
The design of this system has two parts. The first part is the design of the microcontroller based hardware circuit.
The hardware circuit part can be wired on a breadboard for simplifying the development. The controller for this can be
chosen as either AT89C51/52 or AT89S8252. Both of these controllers are from the 8051 family and are pin compatible.
Both of them contain built in program memory. The only difference is that for programming the AT89C51/52 device an
EEPROM/FLASH programmer device is required whereas AT8~S8252 doesn't require a special programmer. It can be
programmed through the In System Programming (ISP) utility running on the firmware development PC and through the
parallel portof the PC. The In System Programming technique for AT89S8252 is described in OLC. For the controller to
work, a regulated 5V de supply is required. For generating a regulated 5V de supply, a regulator IC is used.J<_or the current
design the regulator IC LM7805 from National semiconductor is selected. The input voltage required for this regulator
IC is in the range of 9V to 12V de. A wall mounted de adaptor with ratings 9V or 12V, 250mA can be used for supply-
ing the input power. It is better to use a 9V de adaptor to avoid the excessive heating of the regulator IC. Excessive heat
production in the regulator IC leads to the requirement for heat sinks. The circuit details and the components required to
implement the counter is shown in Fig. 5.15.
The circuit shows the minimal components and the interconnection among them to make the controller operational.
As mentioned earlier, it requires a regulated 5V de supply for powering the controller. The 12 MHZ crystal resonator in
combination with the external 22 picofarad (pF) capacitors drives the on-chip oscillator unit and generates the required
clock signal for the controller. The RC circuit connected to the RST pin of the controller provides Power-On reset for
the controller. The capacitor and resistor values are selected in such a way that the reset pulse is active (high) for at least
2 machine cycle duration. The diode in the reset circuitry is m~ed aJ freewheeling diode and it is not mandatory. The 0.1
Microfarad (0.1 MFD) capacitor connected to the power supply li'ne filters the spurious (noise) signals from the power
supply line. For proper driving; the LEDs should be connected to the respective port pins through pull-up resistors. The •
pull-up resistor values are determined by the forward voltage of LEDs and the current rating of the LEDs. The current
design uses 470 ohms as the pull up resistor. If you are not sure about the forward voltage and current ratings of the LED,
it is better to start with a high value (say 8.2K) for the resistor and replace it with successive low value resistors (4.2 K,
2.7K, 1 K, 870 E, 470 E etc.) till you feel that the brightness of the LED while it is conducting is reasonably good. The
controller contains on-chip program memory and it can be used for storing the firmware. In order to_ use the on-chip pro-
gram memory, the EA\ pin should be tied to Vee· Pulling the EA\ pin to Vee through a high value resistor ensures that the
pin draws v~ry minimal amount of current.
The second part is the design and development of program code (:firmware) for implementing the binary counter and
displaying the counter content using the LEDs interfaced to Port 2. The firmware requirement can be modelled in the
form of a flow chart as given in Fig. 5.16.
 Designing Embedded Systems with 8bit Microcontrollers-805 J

. LM7805

IN4007
+
12MHz
;:; ; 8 220MFD/
-.I + O.IMFD <<: Crystal
<0 25V -
08
(l
l 23

A'rB'>csl/
AT89S~252 LEDSV
'

O.IMFD
~ P'.l
0
l'.l'.l
0
l'.l'.l
0
P:.l
0
w
0
.
t-- t-- t-- t-- t-- t--
'St st st 'St 'St 'St

IN4148/
1N4007
~ ~ ~ ~ ~

Start

1. Initialise Port 2
2. Initialise stack pointer
3. Disable all interrupts (Optional)
4. Initialise counter to zero

Wait for 5 seconds

1. Increment the counter

2. Display the counter content on LED

I
 Introduction to Embedded Systems

Once the finnware requirements are modelled using the flow chart, the next step is implementing it in either proces-
sor specific assembly code or high level language. For the time being let us implement the requirements in 8051 specific
assembly language. The finnware for implementing the binary counter in 8051 assembly language is given below.

; ########################U####################################H####
;Binary Counter.src
;Sour;e-code for impi~ment1ng a binary counter and displaying the
;count through the LE!)s connected to P2.0 to P2.7 port pins
; The LED is· turned on irJ'hen the port line is at logic 0
;The counter va,lue should be complemented to display the count
;using the LEDs connected at Port 2. Written by Shibu KV
;CopyriJht ;(C) •. 20Q8 .. . .. _. . .
; # # #f# ## # # #U ## # H #H # #J# ## # # # #'# ### ## #0 #H ## # ### ### ## # # ## # # ## ## H # # #
ORG O'0QOH :; Re·set ·vector
'JMP ooso·H: ;. Jump to code. mem loc.ation 0050H
ORG O'OO~H ; ·Ex;te.rnal Interrupt o· :ISR location
0

RETI , S.impl y return.' Do. nothing

ORG OOOB.H Timer 0 Interrupt ISR location
RETI Simp).y return: Uo. noth,ing
ORG 0013H , External Interrupt 1 ISP, location
RETI Simply retur'h. Dp nothihg .
ORG 00lBH J Interrupt: lSR. lpcation
RETI ; Simply return. DcLnofhing
ORG 0023H Serial Irrterrupt.-ISR ioc~tion
RETI . . Simply return .. Do. nothing .
ORG 005QH ·; Start of Program_ Execution
MOV P2, #0FFH Turn off all LEDs
CLR EA ; Disable A_ll :irtterr.upts '
MOV SP, #08H Set stack at memory location 08H
MOV R7,#00H Set counter Register R7 to zero.
REPEAT: CALL DELAY Wait for 5 seconds
INC R7 Increment binary counter
MOV A, R-7
CPL A; The LED's ire turned on when corresponding bit is 0
MOV P2, · A. ; Display the count on LEDs connecte_d at Port 2
JMP REPEAT ; Repeat counting
;#i#############################################.#####################
;Routine for generating 5 seconds delay
;Delay generation is dependent on clock frequency
;This routine assumes a clock frequency of 12.00MHZ
;LOOPl generates 248 x 2 Machine cycles (496microseconds) delay
;LOOP2 generates 200 x (496+2+1) Machine cycles (99800microseconds)
;delay. LOOP3 generate 50 x (99800+2+1) Machine cycles
; (4990150microseconds) delay. The routine generates a-
;precise delay of 4.99 seconds
;#######t###t###########################################t###f########
 Designing Embedded Systems with 8bit Microcontrollers-8051

Once the assembly code is written and checked for syntax errors, it is converted into a controller specific machine
code (hex file) using an assembler program. The conversion can be done using a freely/commercially available assembler
program for 8051 or an IDE based tool (like Keil microvison 3). The final stage is embedding the hex code in the program
memory of the controller. If the con,troller used is AT89C5 l, the program can be embedded using a FLASH programmer
device. For controllers supporting In System Programming (ISP), like AT89S8252, the hex file can be directly loaded into
the program memory of the controller using an ISP application running on the development PC.

Design an 8051 microcontroller based control system for controlling a 5V, 2-phase 6-wire stepper motor. The system
should satisfy the following:
1. Use Atmel's AT89C51/52 or AT89S8252 (Flash microcontroller with In System Programming (ISP) support) for
designing the system.
2. Use a 12 MHz crystal resonator for generating the necessary clock signal for the controller.
3. Use on-chip program memory for storing the program instructions.
4. The wires of the stepper motor are marked corresponding to the coils (A, B, C & D) and Ground (2 wires)
5. Use the octal peripheral driver IC ULN2803 from National semiconductors for driving the stepper motor.
6. Step the motor in 'Full step' mode with a delay of 1 sec between the steps.
7. Connect the coil drives to Port 1 in the order Coil A to PLO, Coil B to Pl.l, Coil C to Pl.2, and Coil D to Pl.3
Refer to the description on stepper motors given in Chapter 2 to get an understanding of unipolar stepper motors and the
coil energising sequence for 'Full step' mode.
Figure 5.17 illustrates the interfacing of stepper motor through the driver circuit connected to Port 1 of 8051.

l The flow chart given in Fig. 5.18 models the firmware requirements for interfacing the stepper motor.
From the pulse sequence for runnin~ the stepper motor in 'Full step' it is clear that the pulse sequence for next step

I is obtained by right shifting the current pulse sequence. The initial pulse sequence required is H, H, L, L at coils A, B,
C & D respectively (Please refer to the stepper motor section in Chapter 2). In our case we have only 4 bits to shift and

I our controller is an 8bit controller. Performing a right shift operation of the accumulator moves the LS bit of accumulator
to the MS bit position (Bit position 7 in 0-7 numbering). We want the LS bit to be available at 3rd bit position after each
rotation. This can be achieved by some bit manipulation operation. We can also achieve it by loading the MS nibble of ac-

I cumulator with the same initial sequence HHLL. ln this example we are not using Port Pl for any other operation. Hence
the values of port pins Pl .4 to P1.7 are irrelevant in our case. But in real life scenario it may not be the case always. The
firmware implementation for this is given below:
 Introduction to Embedded Systems

+
3 t
O.lMFD ';2 :s::;
N ~ 8 220MFDl o"
<~ 25V - (l"

!N4148/
lN4007 8.2

• . . 12
22pFI

Start

i
l. Initialise Port Pl to OOH to disable
current flow through all coils
2. Initialise stack pointer
3. Load accumulator with the pulse
sequence for first rotation

,..
~

'.
Output accumulator content to Port Pl
Rotate Accumulator to Right

....
Wait for 1 second
 Designing Embedded Systems with 8bit Microcontrollers-8051

;################################################1#~#################
; Stepper_motor. src_. Firmware for Interfacing stepper motor
; The stator coils A, B, ·c and. Dare. controlled through Port pins Pl. O_,
; Pl .1, ,Pl. 2 and Pl. 3 respectively.
;Accum:ulato~-is used for generating the pulse sequence.for 'Fullstep'
· ;The initial pulse sequence is represented by OCH
; }Wrh:te~ & Compiled for A51 Assembler. Writt~n by Shibu K V
\'';tbpyright · (ci 2.003 · , ·· ·· .. · · · ·· ... ·
~;##############################tttti#~t######Jjf#tl#tl##i#ll####J#t##
::cORG,:OOQOH ; , Reset vector :, , ···· · ,. ·· ·
·· JMP 0100H Jump to ;;de mem 16catiori 0100H to "start-
.::: ,, e,l;(~tution :, .• ••· ·;:
;'.pgG OO.A,3H -.. . E~ternal Tnterr-upt .0. ISR ,Jo9at:j._or1_
'l: .}\ETI Simply .return,.' Do nothin'g ._.· · '
<oRG 99QBH . , Tim,,er ;O InterrupJ ISR )oc;ation ·.
. , fETJ: r Siprp.ly retµrn. Do nothing
· .QRG 0013H ; ExternaL Interrupt 1 ISR location
RETI ; Simply return. Do nothing
'9RG -0,0lBH ·; ..~in:ie:r' 1 Interr,upt ISR l9_cation
RETI ; Simply return. Do nothing
· ORG 0023H ; Serial Interrupt ISR location
RETI ; Simply return. Do nothing
; #,, u # ##' # ## # # # ## ## # # ## ## # ## ### # ## ## # #' ## # ## ## # # ,>.,
UJ# ##.U' ,'#'#' ##.#
'
## # #'# U ## ##
; Start of main Prbgram
ORG 0100H
MDV Pl, #OOH Turn off the·drives to all stator coils
MOV SP, #08H Set stack at memory location 08H
MOVA, #OCCH Load the initial pulse sequence
REPEAT: MOV Pl, A Load Port Pl with puls~ sequence
RR A ; Rotate Accumulator to right
CALL DELAY Wait for 1 second
JMP REPEAT Load Port Pl with new pulse sequence
;####################################################################
;Routine for generating 1 second delay
;Delay generation is dependent on clock frequency
iThis routine assumes a clock frequency of 12.00MHz
;LOOPl generates 248 x 2 Machine cycles (496microseconds) delay
;LOOP2 generates 200 x (496+2+1} Machine cycles (99800microseconds}
;delay. LDOP3 generate 10 x (99800+2+1) Machine cycles
; (998030microseconds) delay. ;The routine generates a-
; precise delay of 0.99 seconds
;######################if############################################
DELAY: MOV R2, #10
LDOPl: MDV Rl, #200
LOOP2: MOV RO, #248
LOOP3: DJNZ RO, LOOP3
DJNZ Rl, LOOP2
DJNZ R2, LOOPl
RET
END ;END of Assembly Program
 Ii
Introduction to Embedded Systems
I
\
I
';

l
Design an 8051 microcontroller based system for interfacing the Programmable Peripheral Interface (PPI) device 8255.
The system should satisfy the following: . __ .
l. Use Atmel's AT89C51/52 or AT89S8252 (Flash microcontroller with In System Programming (ISP) support) for
designing the system
2. Use a 12 MHz crystal resonator for generating the necessary clock signal for the controller. Use on-chip program
memory for storing the program instructions
3. Use Intersil Corporation's (wwww.intersil.com) 82C55APPI device
4. Allocate the address space 8000H to FFFFH to 8255. Initialise the Port A, PortB and Port C of 8255 as Outp~t ports
inMode0
Here we are allocating the addre_s~_§Q.ace 8000H to FFFFH to 8255. Hence the 8255 is activated when the· 15 th bit of
address linecbecomes I. Here we have to use a single NOT gate to invert theA15 line before applying it to the Chip Select
(CS\) line of 8255. In this configuration 8255 requires only four address space namely 8000H for Port A, 8001H for Port
B, 8002H for Port C and 8003H for the Control Register. Rest of the address space 8004H to FFFFH is left unused. Here
we have the luxury ofusing the entire address range since we don't have any other devices to connect. In real life appli-
cations it may not be the case. We may have multiple devices sharing the entire address space 0000H to FFFFH ana we
need to select each device in their own address space. In such scenarios the address lines A2 to A15 needs to be decoded
using a combination of logic gates (NAND, AND,.NOT, OR, NOR) and decoders. Figure 5.19 illustrates the interfacing
of 8255 with 805j_

IN4007
+

;: ; < g 220MFD/ + 0.IMFD ~ <

o"
< 0 25V - n"

IMFD
I0MFD +
+~

IN4148/
lN4007 8.2

22pFI 12
0
 Designing Embedded Systems with 8bit Microcontrollers-80S1

The Octal latch 74LS373 latches the lower order address bus (A0-A7) which is multiplexed with the data bus (DO-
D?). A 3 to 8 decoder chip, 74LS138, decodes the address bus to generate the Chip Select (CS\) signal for 8255. Here we
have only one address line (A15) to decode. The rest of the 2 input lines to the decoder (Pins 2 & 3) are grounded. Our
intention is to assert the CS\ signal of 8255 whenA15 line is 1. The I/p condition corresponds to this is 001. The decoded
output for this is Output l (Yl). You can replace the decoder with a NOT Logic IC. The reset line of 8255 is controlled
through port pin PLO. The Reset of 8255 is active high and when 8051 is initialised, the port pin Pl.0 automatically
generates a reset high signal for 8255.
The flow chart given in Fig. 5.20 models the firmware requirements for interfacing 8255 with 8051 controller.

Start

l. Reset Pl .0 to hold the RESET line of 8255 inactive

2. Initialise Stack Pointer
• 3. Load Accumulator with the control word for configuring
8255 Ports
4. Load DPTR with the address-of 8255 control register (8003H)
5. Write the contr.ol word to 8255 Control Register

End

The control word for configuring all the 8255 ports as output ports in mode 0 is shown below. Please refer to the
section on Programmable Peripheral Interface (PPI) given in Chapter 2 for more details on 8255's control register.

The firmware implementation for this is given below.

·{/~~####H*#lt#Jiwwu#######nn#1#Ht#tf.itJftit ···1,,1·r,i¥r+i!Jtt\: "·: .
:tB.25:5. s.r.b'. F.frm~are •for Interfacing -·a255i,,i>;i:f ./ :', \r ._- :,·-:_': -;,\'. _... ·,·.- ~';.-::i
;i~i;$21P: 'iE(:mewoiy mapped at 80.00H to FFE'E,'iHi''fa·fi~} ess- as'sI.gnfuen .,,for·/;\,
i~;v:a,ribtl-s p~rt · and control r~gister ,aie:. ?i.op;f,;A;,;,~.
•'\\-~·//'"· '• ',. __ .; , ' ,, ' " ' ;J • _• . • ;.-'
OQ,Cft{\/-/:/~i-:<> ·: -~, . . . : ..
,,fPort . .B : 80Q1H,
.,:;'.~\.-'..;:,";_ / ·" , ., ... ,;
Port
'
C' : 8002H,
'
Cont:r;:01
',,,•, ••
Regi-.ster;::: 800$.H
<~ '.\···•''·_..,. ://·,.: ... ·"'"~·}.. >. ,.: ,,... ,r<'

, ./Reset of 8255. is. controlled through Rt.:o. of.:8Q~L·.

'J;wi-i.i fon 'j, Cgmpiled for A5 l As.sembler: :wri
tt~,~. ,~y Shll:>1J K V

I
·~\\~~yright \~\}008. . .· ---: ... ::~·:.~,~ ,;c •.: .... ,.::.• _,·!: ,.v<··'•<
·:; H####### U### H# H# ## lf H #### #### H# ##H#HlHn# HH# ## ## n H#H#jt#
ORG 000.0H ; Reset vector _ . ..
JMP MAIN Jump to the agdress 1q~1,. tion po•it1t'ed: by
i the Label 'MAIW to'Jsv~r-t eX~cVtf±trr',:,.
,,()RG :00,03H • ; External rn:tirrupt ..o TSR '. locabi~: ' ·,·

~~iil:;~o,~:~rrr_ · Simply ,return .. l;):9/rfQthinq ;{ :•i:' -.,:;,",· .

·; timer O Inter:rupt.. i!J:·SR:_;location· ,~<.···::f, .-
;;j~f\ , .
~.QR~~O Ql@W,:.
~t/T"'' ,,. RETI
;•:◊RG OOlBH
<: R~_T I
;;::~F;:!;;;;,~i~J:;i~ti1;:t·t-;;;_: .
Timer ·1 Int~r:rupt J~~~~J~c~.tip~ .;'.. >:/¥'.·, ,:,. ;•i
RETI ; Simply return .. Do nothing .· ·
 Introduction to Embedded Systems

· ;_ $erial In_t~:r:')::1pt ;rsR location

,'siiftpiy<:tet·' n::\·D.o ..not~:ing ... · . . .
ilitfHlf
:~~}~y:J:Jt:;_,i>
,{"-:.<~•._;;
UJUh##HJU#'.fon,,
,:>':,l ·ft;,_-,fY;/~.:~ ,/;
;<),?,' ·;,_,/;' - - .:: ~t C \"'_-.;_ :./' ., • ··::\'' i i_:..

. ;~:i~(j'{ttJ: ,'', L'. h' '

dr,y · fodation ,.oete·

d_.,;,

5.3.6 Interrupts
Before going to the details of 8051 interrupt system, let us have a look at interrupts in general and how
interrupts work in microprocessor/controller systems.
S.3.6.1 What is Interrupt? As the natne indicates, interrupt is something that produces some kind
of interruption. In microprocessor and microcontroller systems, an interrupt is defined as a signal that
initiates changes in normal program execution flow. The signal that generates changes in normal pro-
gram execution flow may come from an external device connected to the microprocessor/controller,
req_uesting the system that it needs immediate attention o~ the interrupt signal may come from some of
the internal units of the processor/controller such as timer overflow indication signal. The first type of
interrupt signals are referred as external interrupts.
S.3.6.2 Why Interrupts? Froma programmer point of view interrupt is a boon. Interrupts are very
useful in situations where you need to read or write some data from or to an externally connected device.
Without interrupts, the normal procedure adopted is polling the device to get the status. You can write
your program in two ways to poll the device. In the first method your program polls the device continu-
ously till the device is ready to send data to the controller or ready to accept data from ~he controller.
This technique achieves the desired objective effectively by sacrificing the processor time for that single
task. Also there is a chance for the program hang up and the total system to crash in certain situations
where the external device 'rails or stops functioning. Another approach for implementing the polling
technique is to schedule the polling operation on a time .slice basis and allocate the total time on a shared
basis to rest of the tasks also. This leads to much more effective utilisation of the processor time. The
· biggest drawback of this approach is that there is a chance for missing some information coming from
the device if the total tasks are high in number. Your device polling will get another chance to poll the
device only after the other tasks are done at least once. .
Here comes the role of interrupts. If the external device supports interrupt, you can connect the inter- l
rupt pin of the device to the interrupt line of the controller. Ehable the corresponding interrupt in firm-
ware. Write the code to handle the interrupt request service in a separate function and put the other tasks
in the main program code. Here the main program is executed normally and when the external device
asserts an interrupt, the main program is interrupted and the processor switches the program execution
to the interrupt request service. On finishing the execution of the interrupt request service, the program
flow is automatically diverted back, to the main stream and the main program' resumes its execution
exactly from the pbint where jt got interrupted.
 Designing Embedded Systems with 8bit Microcontrollers-8051

5.3.6.3 Use of Interrupts In any interrupt based systems, interrupts are mainly used for accom-
plishing the following tasks:
1. I/O data transfer between peripheral devices and processor/controller
2. Timing applications
3. Handling emergency situations (e.g. switch off the system when the battery status falls below the
critical limit in battery operated systems)
4. Context switching/Multitasking/Real-Time application programming
5. Event driven programming

5.3.7 The 8051 Interrupt System

I hope by now you got reasonably good information on interrupts and interrupt handling. Now let us
move on to the interrupt system -0:f 8051 microcontroller. The basic 8051 and its ROMless counterpart
803 lAH supports five interrupt sources; namely two external interrupts, two timer interrupts and the se-
rial interrupt. The serial interrupt is an ORed combination of the two serial interrupts; Receive Interrupt
(RI) and Transmit Interrupt (TI).
5.3. 7.1 Enabling Interrupts The interrupt system of 8051 can be enabled or disabled totally under
software control. This is achieved by setting or clearing the global interrupt enable bit of the Special
Function Register Interrupt Enable (IE). Also, each interrupt can be enabled or disabled individually by
setting or clearing the corresponding interrupt enable bit in the SFR Interrupt Enable.
Interrupt Enable (IE) (SFR-ABH) The bit details of the Interrupt Enable Register is given below:

The table given below explains the meaning and use of each bit.

t
I
l
EXO Ert&blfEiterii~l O . EXO=f eri1ibfoE~t~riiJlirit~rhtpto: ~XO = () <l.is;bles it .
The following code snippet illustrates the enabling of Timer O interrupt and disabling of all other
interrupts.
ORL IE, #10000010B Set bits EA & ET0. Preserv.e other
bits as such
·. #11.'1000108 Reset bits ES, ETl, EXl and EX0.
Preserve other bits such as
I

Introduction to Embedded Systems

The instruction ORL IE, #100000-1 OB sets the global interrupt enabler bit EA(IE. 7) and the Timer 0
Interrupt enabler bit ET0 (IE. I). The status of all other bits in the IE register is preserved. The instruc-
tion ANL IE, #1110001 OB preserves the status of the global intem1pt enabler bit EA(IE. 7), theRSD (IE.6
& IE.5) bits and the Timer OInterrupt enabler bit ET0 (IE.I) and resets the Serial interrupt enabler bit
ES(IE.4), Timer l Interrupt enabler bit ETJ (IE.3), External Interrupt l enabler bit EXI (IE.2) and Ex-
ternal Interrupt O enabler bit EX0 (IE.OJ. This ensures that the reserved bits RSD (IE.6 & IE.5) are left
untouched. The same can also be achieved by individually setting or clearing the corresponding bits of
IE register using SETB and CLR instructions. This requires more number of instructions to achieve the
result.
Note: Though the corresponding interrupt bits are 'set' in the IE register, th~ Interrupts will not be en-
abled and serviced if the global interrupt enabler, EA bit of the Interrupt Enable Register (IE) is 0.
S. 3. 7.2 Setting Interrupt Priorities In a Real World application, interrupts can occur at any time
(asynchronous behaviour) and different interrupts may occur simultaneously. This may confuse the pro-
cessor on deciding which interrupt is to be serviced first. This arbitration problem is resolved by setting
interrupt priorities. Interrupt priority is configured under software control. The Special Function Regis-
ter Interrupt Priority (IP) Register is the one holding the interrupt priority settings for each interrupt.
Interrupt Priority Register (IP) (SFR-BBH) The bit details of the Interrupt Priority Register is ex-
plained in the table below.

The table given below explains the meaning and use of each bit in the IP register.

'-":;,

PXl
';'"'•· o:· -~Qxiif.
PTO Timer Ointerrupt :priority ,, . :·:·

PXO Exte11ll\t O':hli~riitpt:pfici~io/ ,;c>t, · ¥:go ~- ! lii~jtW~[f

The interrupt control system of 8051 contains latches to hold the status of each interrupt. The status
of each interrupt flags are latched and updated during S5P2 of every machine cycle (Refer to machine
cycles for information on S5P2). The latched samples are polled during-the following machine cycle.
If the flag for an enabled intem1pt is found to be set in S5P2 of the previous cycle, the interrupt system
transfers the program flow to the corresponding interrupt's service routine in the code memory (Pro-
vided none of the conditions described in section "Different conditions blocking an interrupt" blocks the
vectoring of the interrupt). The Interrupt Service Routine address for each interrupt in the code memory
is listed below.
'
Interrupt num~er Interrupt source
~~-·•. - _,;xi. ,,- . ., ."- M:F:>··",, ..:\Y·',.,
.. . ~

0 External interrupt O
TimefO int~rrupt
 Designing Embedded Systems with 8bit Microcontrollers-8051

It is to be noted that each Interrupt Service Routine (ISR) is allocated 8 bytes of code memory in the
code memory space.
From the IP Register architecture it is obvious that each interrupt can be individually programmed to
one of two priority levels by setting or clearing the corresponding priority bit in the Interrupt Priority
Register. Some general info on 8051 interrupts is given below: ·
1. If two interrupt requests of different priority levels are·received simultaneously, the request of
higher priority interrupt is serviced.
2. If interrupt requests of the same priority level are received ·simultaneously, the order in which the
interrupt flags are polled internally is served first. First polled first served. (Al~o known as internal
polling sequence.)
3. A low-priority interrupt can always be interrupted by a high priority interrupt.
4. A low-priority interrupt in progress can never be interrupted by another low priority interrupt.
5. A high priority interrupt in progress cannot be interrupted by a low priority interrupt or an '
interrupt of equal priority.
5.3.7.3 Different conditions blocking an Interrupt It is not necessary that an interrupt should
be serviced immediately on request. The following situations can block an interrupt request or delay the
servicing of an interrupt request in 8051 architecture.
1. All interrupts are globally disabled by clearing the Eriable All (EA) bit oflnterrupt Enable regis-
ter.
2. The interrupt is individually disabled by clearing its corr~m;1onding enable bit in the Interrupt
Enable Register (IE).
3. An interrupt of higher priority or equal priority is already in progress.
4. The current polling machine cycle is not the final cycle in the execution of the instruction in
progress (To ensure that the instruction in progress will be completed before vectoring to the inter- (
rupt service routine. In this state the LCALL generation to the ISR location is postponed till the
completion of the current instruction).
5. The instruction in execution is RETI or a write to the 1E/IP Register. (Ensures the interrupt related
instructions will not make any conflicts).
In the first three conditions the interrupt is not serviced at all whereas conditions 4 and 5 services the
interrupt request with a delay.
.
5.3. 7.4 Returning from an Interrupt Service Routine An Interrupt Service Routine should end
with an RETI instruction as the last executable instruction for the corresponding ISR. Executing the
RETI instruction informs the interrupt system that the service routine for the corresponding interrupt
is finished and it clears the corresponding priority-X (X=l High priority) interrupt in progress flag by
clearing the corresponding flip flop. This enables the system to accept any interrupts with low priority
or equal priority of the interrupt which was just serviced. Remember an interrupt of higher priority can
always interrupt a lower priority even if the corresponding priority's interrupt in progress flag is set.
Executing the RETI instruction POPs (retrieves) the Program Counter (PC) content from stack and the
program flow is brought back to the point where the interruption occurred.

-
 Introduction to Embedded Systems
r
I
'l

In operation, RETI is similar to RET where RETI indicates return from an Interrupt Service Routine
and RET indicates return from a normal routine. RETI clears the interrupt in progress flag as well as
POPs (retrieves) the content of the Program Counter register to bring the program flow back to the point
where it got interrupted. RET instruction only POPs the content of the Program Counter register and
brings the program flow back to the point where the interruption occurred.
Will a non serviced Interrupt be serviced later? This is a genuine doubt raised by beginners in
the 8051 based system design. The answer is 'No'. Each interrupt polling sequence is a new on~ and it
happens at S5P2 of each machine cycle. If an interrupt is not serviced in a machine cycle for the reason
that it occurred simultaneously with another high priority interrupt, will be lost. There is no mechanism •
in place for holding the non serviced interrupts in queue and marking them as pending interrupts and
servicing them later.
S.3.7.S Priority Levels for 80S1 Interrupts By default the 8051 architecture supports two levels
of priority which is already explained in the previous sections. The first priority level is determined by
the settings of the Interrupt Priority (IP) register. The second level is determined by the internal hard-
ware polling sequence. The internal polling sequence based priority determination comes into action if
two or more interrupt requests of equal priority occurs simultaneously. The internal polling based prior-
ity within the same level of priority is listed below in the descending order of priority. I

S.3.7.6 What Happens when an Interrupt Occurs? On identifying the interrupt request num-
ber, the following actions are generated by the processor:
1. Complete the execution of instruction in progress.
2. The Program Counter (PC) content which is the address of the next instruction in code memory
which will be executed in normal program flow is pushed automatically to-the stack. Program
Counter Low byte (PCL) is pushed first and Program Counter High (PCH) byte is pushed next.
3. Clear the corresponding interrupt flags if the interrupt is a timer or external intem1pt (only for
transition activated (edge triggered) configuration).
4. Set interrupt in progress flip flop.
5. Generate a long call (LCALL) to the corresponding Interrupt Service Routine address in the code
memory (Known as vectoring of interrupt).
S. 3. 7. 7 Interrupt Latency In the 8051 architecture, the interrupt flags are sampled and latched at
S5P2 of each machine cycle. The latched samples are polled during S5P2 of the following machine
cycle to find out their state. If the polling process identifies a priority interrupt flag's flip flop as set,
an LCALL to its ISR location is generated (If and only if none of the conditions listed under the topic
"Different conditions blocking an interrupt" blocks it). Interrupt latency is the time elapsed between
the assertioc (lf the intem1pt and the start of the ISR for the same.
 Designing Embedded Systems with 8bit Microcontrollers-805 I

Time

Interrupt latency is highly significant in real-time applications and is very crucial in time-critical
applications. Interrupt latency can happen due to various reasons. For external interrupts there is no
synchronisation with the system (asynchronous in behavi9ur) and so it can occur at any point of time.
But the processor latches each interrupt flag only at S5P2 of each machine cycle. So there is no point
even if the interrupt occurs at SlPl of the machine cycle. It is latched only at S5P2 of the current ma-
chine cycle and the latched interrupts flags are polled at S5P2 of the following machine cycle and an
LCALL is generated to the corresponding ISR, if no other conditions block the call. So this delay itself
contributes a significant part in interrupt latency. Even if the ISR is entered some delay can be happened
by the number ofregister contents to be stored (PUSH instructions) and other actions to be taken before
executing the ISR task. The interrupt latency part which contributes the delay in servicing the ISR is the.
sum of the following time delays.· "-
Time between the interrupt assertion to the start of state S5 of current machine cycle (polling cycle}
+ (Time for S5 & S6) + Remaining machine cycles for the current instruction in execution (The current
execution should not be RETI or instructions accessing registers IE or IP, if so there will be an additional
delay of the execution time for the next instruction) + LCALL generation time. The LCALL generation·
time is 12 T States (2 Machine cycles).
If the current machine cycle (the polling cycle) is the last cycle of the current instruction in execution'
and the current instruction in execution is other than RETI or instruction accessing IE or IP register, the
interrupt vectoring happens at the shortest possible time and it is given as
Time between the interrupt asserted to start of state S5 of current machine cycle (polling cycle)
+ (S5+S6 T state+ 12 clock)
= Time between the Intenupt Asserted
.
to the start of state S5 + (((1 +1+ 12) x 2)/fosc) seconds.
(1 T state= 2 clock cycles and 1 clock cycle= 1/fosc)
The minimum time required to identify an interrupt by the system is one machine cycle, i.e. if an
interrupt occurs at· S5 of a machine cycle, it is latched and it is identified as an intenupt at state S5
of next machine cycle (Polling cycle). Hence the minimum time from interrupt assertion to S5 of the
polling machine cycle is 1 machine cycle (12 clock periods). The maximum time required to identify
an interrupt by the system is approximately 2 machine cycles. Assume the interrupt is asserted at state
S6 of a machine cycle, it is latched at S5 of next machine cycle and the latched value is polled at S5 of
next machine cycle. Hence the minimum time between the 'Interrupt Asserted' to state S5 of the current
machine cycle (polling cycle) is 6 T States (1 machine cycle). That means State S6 of previous machine
cycle to state S5 of cunent machine cycle. Hence the minimum acknowledgement time will be 20 T
States (Since 1 machine cycle = 6 T states. The approximate response delay will be 3 machine cycles).
3 machine cycles is the minimum response delay for acknowledging an interrupt in a single inter-
rupt system. There may have additional wait times which come as an addition to the minimum response
 Introduction to Embedded Systems

delay, depending on some other conditions. If you look back to the section "Different conditions block-
ing an Interrupt" you can see that if the current machine cycle when the interrupt asserted (The machine
cycle at which the interrupt is latched) is the last machine cycle of the current instruction in progress, the
interrupt vectoring wilLhappen only after completing the next instruction. If the instruction in progress
is not in its final machine cycle, the maximum additional waiting (waiting time excluding the LCALL
generation time) time required to vector the Interrupt cannot be more than 3 machine cycles since the
longest instructions MUL AB and DIV AB are 4 cycle instrnctions. If the instrnction in progress is a
RETI instrnction or any access to IP or IE register then also the vectoring of the interrupt service routine
will be delayed till the execution of next instruction. If the next instruction following the RETI or IP/IE
register related instruction is MUL AB or DIV AB; the additional wait time will be 5 machine cycles
(RETI and IP/IE related instrnctions are 2 machine cycle instructions).

I
In brief, the response time for interrupt in 8051 system is always more than 3 machine cycles and less
than 9 machine cycles.
5.3. 7.8 Configuring External Interrupts 8051 supports two external interrupts, namely, Exter-
nal interrupt Oand External interrupt 1. These are hardware interrupts. Two port pins of Port 3 serve the
purpose of external interrupt input line. External interrupts are usually used for connecting peripheral .
devices. The external interrupt assertion can be either level triggered or edge triggered depending on
the external device connected to the interrupt line. From the 8051 side it is configurable and the con-
'figuration is done at the SFR Timer/Counter Control Register (ICON). Bits TCON.0 and TCON.2 of
ICON register configures the same for External Interrupt 0 and 1 respectively. TCON.0 is also known
as Interrupt 0 type control bit (ITO). Setting this bit to l configures the external interrupt Oas falling edge
triggered. Clearing the bit configures the external interrupt b as low level triggered. Similarly, TCON .2
is known as Interrupt 1 type control bit (ITl ). Setting this bit to 1 ~onfigures the external interrupt 1 as
falling edge triggered. Clearing this-hit configures the external interrupt 1 as low level triggered.
For external interrupts, the interrupt line should be asserted by the externally connected device to a
minimum time period of the interval between two consecutive latching, i.e. S6Pl of previous machine
cycle to S5P2 of current machine cycle ( 1 Machine cycle). Otherwise it may not be identified by the pro-
cessor (Only interrupts which are found asserted during the latching time (S5P2) will be identified).
5.3.7.9 Single Stepping Program with the Help of External Interrupts Single stepping is
the process of executing the program instrnction by instrnction. This can be achieved with the help of
the external intenupt 0 or 1 and a small firmware modification. This works on the basic principle that
an interrupt request will not be acknowledged if an interrupt of equal priority is in progress and if the
instrnction in progress when the interrupt is asserted is a RETI instrnction, the vectoring will happen
•only after executing an instruction from the main program, which is interrupted by the interrupt. If the
external interrupt is in the asserted state, the interrupt vectoring happens after executing one instruction
from the main program. This execution switching between the main program and ISR can be achieved
by a simple ISR firmware modification. Com1ecting a push button switch to the external. interrupt line
0 through a resistor is the only hardware change needed for a single step operation (Fig. 5.22). Config-
ure INTO as level triggered in firmware. Activating the push button asserts the INTO interrupt and the
processor starts executing the ISR for interrupt 0. At the end, the ISR waits for a 1 to 0 transition at the
INTO line that asserts the external interrupt 0 again. The next instruction that is going to be executed on
asserting the INTO is RETI and according to the general interrupt vectoring principle the processor will
go back to the point in the main code where it got interrupted and after completing one instruction it will
again come back to the INTO ISR. This process is repeated.
 Designing Embedded Systems with 8bit Microcontrollers-80S 1

Single stepping can also be done with external inter-

rupt 1. Make external interrupt 1 as level triggered and
connect the hardware set up to pin P3.3 (external inter-
rupt 1 line) and modify the ISR for external interrupt 1
as explained for external interrupt O ISR. It will work
fine. Single stepping is a very useful method in debug-
ging the application. It gives an insight into the various
effects produced by the execution of an instruction, like
registers and memory locations modified as a result of
the execution of an instruction.

Design an 8051 microcontroller based data acquisition system for interfacing the Analog to Digital Converter ADC,
ADC0801 from National semiconductors. The system should satisfy the following:
1. Use Atmel's AT89C51/52 or AT89S8252 (Flash microcontroller with In System Programming (ISP) support) for
designing the system. Use a 12MHZ crystal resonator for generating the necessary clock sigdal for the controller.
Use on-chip program memory for storing the program instructions. ·
2. The data lines of the ADC is interfaced to Port 2 of the microcontroller. The control signals (RD\, WR\, CS\) to the
ADC is supplied through Port 3 pins of microcontroller.
3. The Analog voltage range for conversion is from OV to 5. The varying analog input voltage is generated from the
5V supply voltage (Vee) using a variable resistor (Potentiometer). The ADC asserts its interrupt line to interrupt the
microcontroller when the AD conversion is over and data •is available at the ADC data port.
4. The microcontroller reads the data on receiving the interrupt and stores it in the memory. The successive data con-
version is initiated after reading the converted data for a sample. Only the most recent 16 samples are stored in the
microcontroller memory.
This example is a good starting point for a discussion on data converters and their use in embedded applications. The
processing/controlling unit (The core of the embedded system) of every embedded system is made up of digital systems
and they work only on digital data. The processor/controller is capable of dealing with binary (digital) data only. As men-
tioned in the beginning, embedded systems are in constant interaction with the real world through sensors and actuators.
In most of the situations, the signals which are handled by embedded systems fall into the category 'analog'. Analog
signals are continuous in nature. Most of the embedded systems used in control and instrumentation applications include
the monitoring or control of at least one analog signal. The thermocouple-based temperature sensing system used in in-
dustrial control is a typical example for this. The thermocouple generates millivoltage (mV) in response to the changes in
temperature. This voltage signals are filtered and signal conditioned and then applied to the monitoring system for moni-
toring and control purpose. Digital systems are not capable of handling analog signals as such for processing. The analog
input signal from sensors needs to be digitized (quantized) before inputting to the digital systems. In a similar fashion, the

I output from digital systems are digital (discrete) in nature and they cannot be applied directly to analog systems which
require continuous signals for their operation. The problem of handling the analog and digital data in embedded systems
is handled by data converters. Data converters fall into two categories, namely; Analog to Digital Converters (ADC)
and Digital to Analog Converters (DAC). Analog to Digital Converter (ADC) converts analog signals to corresponding
digital representation, whereas Digital to Analog Conve1ter (DAC) converts digital signals to the corresponding analog
representation.
ADCs are used at the input stage of the processor/controller and DA Cs are used at the output stage of the processor/
controller. ADCs and DACs are available in the form oflntegrated Circuits (ICs) from different manufacturers'. These
chips are used for interfacing the processor/controller with sensors/actuators which produces/requires analog signals.
Analog to digital conversion can be accomplished through different conversion techniques. Successive approxima-
tion and integrator are the two commonly adopted analog to digital conversion techniques. In the successive approxi-
 Introduction to Embedded Systems

mation technique, the input analog signal is compared against a reference voltage. The reference voltage is adjusted till
it matches the input analog voltage. The integrator technique changes the input voltage to time and compares the new
parameters with known values. Discussing each technique in detail is out of the scope of this book (The current scope is
limited to how data converters are used in embedded system designs) and readers are advised to refer books dedicated on
digital systems/data acquisition systems. The successive approximation teclmique is faster in data conversion and at the
same time less accurate, whereas, integrator technique is highly accurate but the conversion speed is slow compared to
successive approximation technique. The successive approximation AD Cs are used in embedded systems like control and
instrumentation systems, which demands high conversion speed. The Integrator type ADCs are used in systems where the
accuracy of conversion required is high. A typical example is a digital multimeter.
ADCs convert analog voltages in a given range to a binary data within the range supported by the ADC register. For
example, for an 8bitADC, the voltage range Oto 5 Vis represented with binary data OOH to FFH. The voltage range (5-0)
is split across the 256 (0 to 255) steps. Hence the resolution of the ADC is represented as 1/256, meaning the binary data
is incremented by one for a rise in 1/256 V in the input voltage. The resolution offered by the ADC depends on the input
voltage range and the register width of the ADC. ADC can be used for the conversion of +ve as well as -ve voltage and
range ofl/p with offset from 0. It is the responsibility of the firmware developer to interpret all these conditions based on
the system design. For example, if the input voltage is in the range 1 to 5V, the ADC represents 1 as OOH and 5 as FFH.
The firmware developer should handle this appropriately.
The IC ADC0801ADC from National Semiconductor is an example for successive approximation ADC. The
ADC0801 is designed in such a way that its tri-stated output latches can directly drive the processor/controller data bus/
po1t. ADC0801 appears as a memory location or I/0 port to the processor/controller and it doesn't require any additional
bus interface logic. The logic inputs and outputs of ADC0801 meets both TTL and CMOS voltage level specifications and
it can be used with processors/controllers from the CMOS/TTL logic family without using any interface conversion logic.
ADC0801 supports input voltage range from Oto 5V and two inputs, VIN(+) and VIN(-) for differential analog voltages.
The input signal is applied to V1i+) and V1N(-) is grounded for converting single ended positive voltages. For single
ended negative voltage conversion, the input voltage is applied to V1N(-) and VIN(+) is grounded. ADC0801 provides an
option for adjusting the span (range) of input voltage for conversion. The span adjustment is achieved by applying a volt-
age, which is halfof the required span, at the VRE/2 (Pin NO. 9) of ADC0801. For example, if the required span is 3V,
apply a voltage 1.5V at pin VRE/2. This converts the input voltage range 0V to 3V to digital data OOH to FFH. Keeping
the VREF/2 pin unconnected sets the span to 5V (The input varies from 0V to 5V). If the span is less than 5 and the range
of input signal starts with an offset from 0V, the same can be achieved by applying corresponding voltages at pins VREF/2
and VIN(-). As an example consider the requirement where, the span is 3V and range is from 0.5V to 3.5V, a voltage
of 1.5V is app,lied to Pin VRE/2 and 0.5V to pin V1N(-).The AD converter requires a clock signal for its operation. The
minimal hardwate connection required to build the AD conve1ter system is shown in Fig. 5.23.
The AD converter contains an internal clock generator circuit. For putting the chip into operation, either an ex-
ternal clock or the built in clock generator can be used. ADC0801 provides a pin, CLK IN (Pin No. 4), for connect-
ing external clock signal. The external clock signals can be generated using an oscillator circuit or the clock signal
available from the CLK OUT pin of the microcontroller can be applied to the CLK IN. The internal clock generator
circuit of the ADC can be used for generating the necessary clock signal to the system by connecting an external resis-
tor and capacitor across the pins CLK IN and CLK R as shown in the schematic. The CLK IN pin is internally con-
nected to the input pin of a Schmitt trigger and CLK R is connected to the o/p pin of the Schmitt triggers as shown
in Fig. 5.24.
The frequency of the circuit is represented as fCLK = 1/1.1 RC. The frequency range for ADC0801 is in the range
100 kHz to 800 kHz
ADC080 I requires three necessary control signals namely; RD\, WR\, CS\ for its operation. The CS\ signal is used for
activating the ADC chip. For starting a conversion, the CS\ and WR\ signals should be asse1ted low. The internal Succes-
sive Approximation Register (SAR) of the chip is reset and the output data lines of the ADC enter high impedance state
on asserting the WR\ signal. The data conversion begins when the WR\ signal makes a transition from asserted state to
high. The ADC asserts the line INTR\ on completion of the conversion. This signal generates an interrupt at the processor.
The converted digital data is available on the data bus of the AD.C from the moment when the INTR\ line is asserted low.
The INTR\ signal is reset when the RD\ signal is asserted low by the processor. -
 Designing Embedded Systems withBbit Microcontrollers-8051

IN4007
+
3
co ' +
r::i < 8 220MFD/
<- 25V - 2

+
lOMFD lOMFD
/4 I ) +

1N4148/
1N4007 8.2K

CLK:R
119
I
I
R I
I
I
I
CLK:IN CLK
C ,4
I
I .

I I
I
I
I

In the current design, a potentiometer is used for varying the voltage from OV to 5V. The data lines of the ADC are
interfaced to Port 2 of the control)er. The control signals to the ADC are supplied through the pins of Port 3. Port Pin P3.3
supplies the Chip Select (CS\) signal and Port.Pin P3.0 supplies the RD\ Signal to the ADC. The WR\ signal to ADC is
 Introduction to Embedded Systems

supplied through Port Pin P3 .1. The INTR\ signal line of ADC is interfaced to the External Interrupt O(INTO\) line (Port
Pin P3.2) of 8051. The flow chart given in Fig. 5.25 illustrates the firmware design for the system.

ADC main routine External interrupt 0

start routine

l. Initialise Port 2 as I/p port

2. Initialise stack pointer
3. Disable all Interrupts (Optional) l. Read the data from ADC
2. Store the read data in memory location
3. Reset the ADC interrupt

I
4. Deselect the ADC chip
l. Select the ADC chip 5. Decrement the counter and reset the
2. Clear the interrupt line of ADC memory location to store the nex_t sample
3. De-select ADC chip to the start address of storage memory if
l
4. Set the counter for sample counting the counter value is zero
5. Select the start address of storage 6. If the decremented counter value is non-
memory for storing the first sample zero increment the memory location to
store the next sample

1. Set External 0 Interrupt as level

triggered
2. Enable interrupts and EXT0 Interrupt
3. Select the ADC
4. Assert the Start of Conversion signal
, "'
l. Reset the EXT0 Flag
2. Select the ADC chip
3. Assert Start of Conversion signal
Wait forever

( Fig..5.25) · Flow chartfor interfacing inc9s0,i

The finnware for interfacing the ADC in 8051 Assembly language is given below.

;######t####t#####t#######tl#t#f#####ii#############t################
; adc0801 interrupt. src. Firi:nwa?e' for inte,r:facing ADC801 with 8051
; ADC - 8b51 Physical Inte.rfa~e details ·
; ADC Data lines connecte<i ._t:.i:5: Pofrt~~-P2 80)1 of,
;CS\ ➔ P3.3; RD\ ➔ P3.0; WR\ ➔ '1h.1; INTR\ ➔ ·P3.2 (INTO\)
;Written by Shibu K V. Copyright (C) 20D8 i
;tl111111111111111t111111111111111tt#t#tt111111111111t11111111111111t
ORG' OOQOH ; Reset vector
JMP 0050H ; .'.Jump to
start of main progrct!Il
ORG O003H . ., ·; .ExternaL Interrupt: D -ISR location
, The ISR will not fit.In ,;a bytfs:.,,she.
; ·11Ejrf¢e lt is implem~'ri.ted;_~s:;;ep~r;j:e routine
. CAIJk/.EXTERNAL INTRO ; Funct,.i:on:Jmplel!IE:nting E,xtnl o· routine
'··.,.;v:.:r;-' ·:·-: ' '! - i;:~e'i_._:b, rtf;r•'~-;.; l:}:h ,'J{:! .,,; ' ,, • .
·~._:.·•.
 Designing Embedded Systems with 8bit Microcontrollers-8051

ORG OOOBH Timer O Interrupt ISR location

- RETI ; Simply return. Do nothing
ORG 0013H External Interrupt 1 ISR location
RETI Simply return. Do nothing
ORG OOlBH Timer 1 Interrupt ISR location
RETI Simply return. Do nothing
ORG 0023H Serial Interrupt ISR location
RETI Simply return. Do nothing
i1####1##################1##############t######1#########t#f#########
OI}G 0050H ; Start of main Program
MOV ,P2, #DFFH Configure f'ort2 as . input Port .
. MOV SP, #Q8H Set st~ck at memory location 0BH
. CLR P3.3 Select ADC
C:tR P3.0 Clear -Auc•interrupt line-by asserting ADC
RD\
'SETB 1?3. 3 De-select ADC
MOV RO, #16 ; Set the counter for 16 samples
. MOV Rl, #20H Set start of sample storage m,:;:rnloc as 20H
'CLR. ITO . , Set External Interrupt· 0 as low-level
t1;:_ig'gered .
"- · MOV IE, #lO0OO00lb.; Enable only External O interrupt
~. CLR P3. 3 Str;.lect ADC
X¾-SLB-.J'~-}' . ,,- Trigger ADC Conversion; Reset. ADC SAR
'--NOP · -- ; Holdre WR\Sig_nal low for 2 machine cycles
NOP /
._ SETB P3 .1 ;/_;pc{ggle WR\ line from 0 to 1 to initiate-
- ,1 conversion
JMP $ ; Loop for ever
/ . .
;#################t######l###########f############t##################
; Routine for handling External 0 Interrupt
; External 0 Interrupt is asserted when ADC finishes data conversion
;######~#############################################################
EXTERNAL INTRO:
MOV @Rl, P2
CLR P3.0 Assert RD\ Signal to clear INTR\ ADC Signal
line
NOP
NOP

I SETB P3.0
SETB P3.3
DJNZ RO, RETURN
De-select ADC

; The 16 samples are taken

; overwrite the previous samples with new __
MOV Rl, #lFH 20H is the mem loc holding the start of sample
MOV RO, #16 Reload Sample counter with 16
RETURN: INC Rl Increment mern loc to _hold next sample
CLR IE0 Clear the inierrupt O edge detect flag
CLR P3.3 Selec~ ADC
 Introduction to Embedded Systems

CLR P3.1 Trigger ADC Conversion; Reset ADC SAR

NOP Hold the WR\Signal low for 2 machine cycles
NOP
SETB P3.1 Toggle WR\ line to initiate conversion
RET
END ; END of Assembly Program

5.3;8 Timer Units

Timers are very essential for generating precise time reference in any system. Timers can be implement-
ed in either software or hardware. Hardware timers are dedicated hardware units and are highly precise
in operation. The Standard 805.l architecture supports two 16bit hardware timers that can be configured
to operate in either timer mode or external event counting mode. The timers are named as Timer Oand
Timer I. If the timers are configured in timer function moae, the corresponding timer register is incre-
mented once in each machine cycle. Since one machine cycle consists of six I-States (12 clock cycles),
the timer inc:;rement rate is 1112 th of the oscillator frequency (f0 jl2).
If the timer unit is configured for counter mode, the timer register is incremented in response to a one
to zero transition at the corresponding external port pin for counter mode. The external input pins are
sampled during S5P2 of each machine cycle. If the sample shows a high in S5P2 of one machine cycle
and a low in any of the next sampling time, the counter register is incremented by one. The count is up-
dated only at S3P 1 of the machine cycle following the machine cycle in which the transition is detected.
It is obvious that it takes a miniml_lm of two machine cycles to identify a 1 to Otransition (2 machine
cycle corresponds to 24 clock periods). So the maximum count rate for external events is f0 j24, where
fosc is the oscillator frequency (Clock frequency). Timer Oand Timer 1 can be configured as timer unit or
counter unit by using timer/counter modG-Select bit of the special function register Timer/counter Mode
Control (TMOD). Timer Oand Timer 1 can be operated in four different modes. The mode selection is
done by the timer mode select bits ofTMOD register.
Timer/Counter Mode Control Register (TMOD) (SFR-89H)

·•BlT'7
' ci,;;"'
'}3IT6·· B:ITS '\ BIT4 · BIT3 WT2· BITl ·•··BITO
GATE err. Ml· MO GATE err Ml MO
Timer 1 Configuration Timer OConfiguration

The following table explains the meaning and use of each bit in the TMOD register.
.
Bit ·Na}Jle Description
GATE Gating control If this bit is set to I in the corresponding timer configuration nibble
of TMOD, the c01responding timer/counter will be enabled only
when the INTO /INTl (INTO corresponds Timer O/Counter O& INTl
c01resporids Timer I/Counter I) lin~ is high and the corresponding
timer/counter's run bit TR.is enabled in the TCON register. If GATE
bit is 0, the timer/counter will run when the .corresponding timer/
counter's run bit TR is enabled in the TCON register. ·
 Designing Embedded Systems with 8bit Microcontrollers-80S1

. . ' .
· <~The:!imer/Counter Operitidn,~m:ocfe select' bits. lh;aJ.1'. b6 o·
..v•<:the';zi.mo;des. . ' . ·. ' ; •.. . < . , ....

The values for bits MO and Ml and the corresponding mode of operation for the timer/counter is
explained in the table given below.

•. Mode 3 ..TiII1er 1 in this mode simply'.holds its' ¢otltlt5'1t fa\slmil\l,r to'cii;~

Tiineri'ru~}ontrof pit TRl. Tim!cfO i.n this 'rhode configures ~~·two 8b1t ..
TLO ~d 'DHO. TLO is configured by theJimerO configuration n·ibble:iiud: .
configured by the Timer 1 configuration nibble.

Timer/Counter Control Register (TCON) (SFR-88H) It is a bit addressable special function reg-
ister that holds the timer/counter interrupt flags and run control bits.

BIT7 BIT6 BITS. BIT4 BIT3 BIT2 BITl BITO/

TF1 TR1 TFO TRO IEl 1T1 IEO ITO

The following table explains the meaning and use of each bit in the ICON register.

Bit Name Description

Il TFl

TRI
Timer/Counter l overflow flag

Timer/Counter 1 Run control

Set by hardware when timer/counter 1 overflows. The flag is
automatic-ally cleared when timer I interrupt is vectored.
TR1=1 Start timer/counted
TRl=O Stops timer/counter 1
TFO Timer/Counter Ooverflow flag Set by hardware when timer/counter Ooverflows. The :flag is
automatically cleared when timer Ointerrupt is vectored.
TRO Timer/Counter ORun control •TRO = 1 Start Timer/Counter 0
TRO OStops Timer/Count~r Q
IEl External Interrupt 1 edge detect flag Set by hardware when external interrupt 1 edge is detected. Cleared
by hardware when intenupt is vectored
 Introduction to Embedded Systems

5.3.8.1 Timer/Counter in Mode O Timer/Counter-0 and Timer/Counter-I in mode 0 acts as a

13bit timer/counter (Fig. 5.26). The 13bit register is formed by all 8 bits of THO and the lower 5 bits
ofTL0 for Timer/Counter-0 (All 8 bits ofTHl and the lower 5 bits of TLl for Timer/Counter-I). The
timer/counter mode selection is done by the bit C/T of the register TMOD. Timer/Counter-0 & Timer/
Counter-I has separate selection bits as described earlier. If Timer/Counter-0 is configured as timer and
if the corresponding run control bit for Timer/Counter-0 (TR0 in Timer Control Register (TCON)) is
set, registers TLO & THO functions as a 13bit register and starts incrementing from its current value. The
timer register is incremented by one on each machine cycle. When the 13bit Timer register rolls over
from all ls to all Os (FFlFH to O000H), the corresponding timer overflow flag TF0, present in TCON
register ·is set. If the Timer 0 interrupt is in the enabled state and no other conditions block the Timer 0
interrupt, Timer Ointerrupt is generated and is vectored to its corresponding vector address 00OBH. On
vectoring the interrupt, the TFO flag is automatically cleared. Operation of Timer 1 in mode Ois same
as that of Timer O except that for Timer 1, the 13bit timer register is formed by the registers TLl and
THI and the corresponding Timer run control bit is TRI. The Timer 1 overflow flag is TFl and the cor-
responding interrupt vector location for Timer 1 is 00lBH. It is advised to set the GATE control bit to
0 for timer operations. If the GATE control is set to 1, the timer register is incremented in accordance
with each machine cycle only if the corresponding Interrupt line INTRx is high (INTO for Timer Oand
INTl for Timer 1).

THO/THI TLO/TLl

13 bit timer register

( Fig. 5.26) Timer (Counter) Register fot Mode 0

Figure 5.27 illustrates the operation of Timer/Counter in Mode 0

It is to be noted that for mode 0 operation, the lower 5 bits of TLO/TLl (Bit Oto Bit 4) and all 8 bits
1

of THO/THI forms the 13bit register. When the 5 bits ofTLO rolls over from all ls (IFH) to all 0s (00H),
THO is incremented by one. The upper 3 bits ofTL0/TLl is indeterminate (Don't care bits). THO/THI
 Designing Embedded Systems with 8bit Microcontrollers-8051

CIT 0

C/T 1
Counter in ut (TO/Tl Pin)
Timer/Counter function select logic (C/1\)
Timer run control TRO/TRl Timer 0/Timer 1
Interrupt

runs in its full 8bit mode and act as the 8bit counter whereas, only the 5 least sigflific_aµt bit& ofTL0/TLl
undergoes changes in accordance with machine cycle and so TL0/TLI is. said to be acting as a prescaler
32 for the 8bit counter THO/THI. The timer interrupt is generated when the 13bit timer register rolls
over from all ls to all Os, i.e. when THO count is FFH and TLO count rolls from IFH to OOH. The count
range for mode Ois OOO0H to 1FFFH.
S.3.8.2 Timer/Counter in Mode 1 Mode 1 operation of Timer (Counter) 0/Timer (Counter) I is
similar to that.of mode 0 except the timer register size (Fig. 5.28). The timer register is 16bit wide in
mode I. The timer/counter mode selection is done by the bit CIT of the register TMOD. Timer (Counter)
0 and Timer (Counter) 1 has separate selection bits as described earlier. If Timer 0 is configured as a
timer and if the corresponding tun control bit for Timer 0 (TR0 in Timer Control Unit (TCON)) is set,
registers TL0 and THO functions as 16bit register and starts incrementing from its current value. The
timer register is incremented by one on each machine cycle. When the timer register rolls over from all
1s to all Os (FFFFH to 0000H), the corresponding timer overflow flag TF0, present in JCON register
is set. If Timer 0 interrupt is in the enabled state and no other conditions block the Timer 0 interrupt,
Timer 0 interrupt is generated and is vectored to its corresponding vector address 000BH. On vectoring
the interrupt, the TF0 flag is automatically cleared. Operation of Timer 1 in mode 1 is same as that of
Timer 0 except that for Timer I the 16bit timer register is formed by the registers TL 1 and TH 1 and the
corresponding Timer run control bit is TRI. The Timer 1 overflow flag is TFl and the corresponding
interrupt vector location for Timer 1 is 00 lBH.

16bit Timer Register

CIT 0
,'THO/tl:lf:\,
C/T 1
---.·r:,,,s:B1ti!H~l
'--+-~
Counter in ut (TO/Tl Pin) Timer interrupt
Timer/Counter function select logic (C/T\) flags
Timer run control TRO/TRl
Intem1pt

( Fig~ $.28) . Timer (Counter) Of.Timer (Counter) I inlVJ;ode 1

It is advised to set the GATE control bit to 0 for timer operations. If the GATE control is set to 1, the
timer register is incremented in accordance with each machine cycle only if the 0)rresponding Interrupt
line INTx is high (INTO for Timer Oand INT 1 for Timer 1). ·
 Introduction to Embedded Systems

If the counter mode is set, and the corresponding counter run contml_bit (TRO for counter 0 and TRI
for counter 1) is 1, the timer register ((THO & TL0) for Counter 0 and (THl -& TLl) for Counter 1) is
incremented by one on each traceable logic transitions at the counter input pins (TO for Counter 0 and
TJ for Counter 1). The above said actions are followed only if the gating control bit GATE is set to 0. If
GATE is set to 1 the counter (timer) register is incremented by one for each traceable logic transitions
at the counter input pins only when the corresponding Interrupt line INTx is high (INTO for Counter 0
and INT l for Counter 1). The overflow process and interrupt vectoring are similar to that for the Timer0/
Timer 1 operation. ·
5.3.8.3 Timer/G:ounter in Mode 2 (Auto Reload Mode). Timer (Counter) 0/ Timer (Counter) l
in mode 2 acts as 8bit timer/counter (TL0 for Timer (Counter) 0 and TLl for Timer (Counter) 1) with
auto reload on the timer/counter register overflow (TL0 or TL 1Y(Fig. 5.29). The timer/counter mode se-
lection is done by the bit CIT of the register TMOD. Timer (Counter) 0 & Timer(Counter) 1 has separate·
selection bits as described earlier. If Timer 0 is configured as timer and if the corresponding run control
bit for Timer 0 (TR0) in Timer Control Unit (TCON)) is set, register TL0 functions as 8bit register and
starts incrementing from its current value. The timer register is incremented by one on each machine
\ cycle. When the Tinier register rolls over from all ls to all Os (FFH to O0H),-the corresponding t1mer
overflow flag TF0, present in TCON register is set and TL0 is reloaded with the value from THO. THO .
r,emains,unc1¥!nged. If Timer 0 interrupt is i11 the enabled state and no other conditions block the Timer 0
interrupt,Jt:.:is. .vectored to the corresponding vector address 000BH. On vectoring the interrupt, the TF0 ··
flag is automatically cleared. Operation of Timer 1 in mode 2 is same as that of Timer 0 except that for
Timer 1 the 8bit timer register is formed' by the register TL 1 and the corresponding Timer run control bit
is TRI. The Timer 1 overflow flag is TF 1 and the corresponding interrupt vector location is 001 BH. It is
advised to set the GATE control bit to Ofor timer opera!i9ns. If the GATE _control is set to 1, the timer
register is incremented in accordance with each macliine cycle only if the co_rrespondin_g Interrupt line
INTx is high (INTO for Timer Oand INT 1 for Timer 1). . · ·

CIT

CIT
Counter in ut TO/Tl Pin Timer interi:tipt
Timer/Counter function select logic (C/T\) .
Timer 0/Timer 1
flags
Timer run control TRO/TRl-
Interrupt_

If the counter mode is set, andthe corresponding counter run1 control bit (TR0/for counter 0 and TRI
• I
for counter 1) is 1, the timer register (TLO for Counter 0 and TLI for Counter 1)is incremented by one
on each traceable logic transitions at the counter input pins (TO for Counter Oand Tl for Counted).
The above said actions are followed only wben the gating contro!<bit GATE is set to 0. If GATE is\set
/l .· •

to 1, the timer register is increment~d, ~y ?ne for/e~fo tracea~ logic transitions at the counter input
 Designing Embedded Systems with 8bit Microcontrollers-80S1

pins only if the corresponding Interrupt line INTx (INTO for Counter Oand INT 1 for Counter 1) is high.
The overflow process and interrupt vectoring are similar to that of TimerO/Timer 1 operation. Timer 1 in
Mode 2 is generally used for baudrate generation in serial data transmission.
5.3.8.4 Timer/Counter in Mode 3 Timer/Counter Oin mode 3 functions as two separate 8bit Tim-
ers/Counters (Fig. 5.30). TLO acts as the timer/counter register for Timer/Counter Oand THO acts as the
timer/counter register for Timer/Counter 1. TLO uses the Timer Ocontrol bits namely TRO, GATE, C/T,
INTO and TFO. TLO can run in either counter/timer mode by setting or ~learing the C/T bit. Counter
operation is controlled by GATE, INTO pin, TO pin and TRO bit as explained earlier. But the operation is
similar to that of Timer Oin mode 3. In mode 3, THO supports only timer function and does not support
counter function. THO counts only the machine cycles, not external events.

Timer 1 ruq control (TRI) Timer 1

interrupt

CIT
..,
---- fl
C/T 1 ,..,(j)
Counter input (TO/Tl Pin) TimerO 0
Interrupt Flag <
Timer/Counter function select logic (C/1\) ,..,(j)
:;:!:l
Timer Orun control TRO) TimerO 0
interrupt <

The actual Timer 1 (THI TLl ), when configured to run in mode 3, by using the Timer 1 configuration
bits, stops its functioning and simply holds its count.
Thus mode 3 provides an extrn 8bit timer. The original Timer 1 (THl TL 1) can be turned on and off
by switching it out and into mod~ 3 and it can run in either mode 0, mode I or mode 2 apart from mode
3 since the acting Timer 1, THO in mode 3 is forced to run as an 8bit timer by default, by putting Timer
0 configuration bits to mode 3 (MO, Ml of Timer OControl Register= 1). The only shortcoming is that
since THO is responsible generating Timer 1 interrupt when Timer Ois configured in mode 3, no inter-
rupt is generated by the actual Timer 1 (THI TLI) when it runs in mode 0, 1 or 2 with Timer Oin mode
3. But still Timer 1 can. use for applications that doesn't require Timer interrupts like baudrate genera-
tion.

Implement the example 1 given under 'Ports' section (Binary Counter implementation) using timer interrupts.
In the example given under the 'Ports' section, the display delay is implemented using a delay generator loop. The
delay generation can be easily implemented using a timer and the required operations following the delay can be imple-
mented in the timer inierrupt handling routine.
8051 provides two timer units.and they can be operated in four different modes. The timer'units in mode I acts as a
16bit tiilier unit which counts ma.thine cycles from O(OOOOH) ta 65535 (FFFFH) and generates timer interrupt when rolls
\ ' ! ' '
over from 6i535 (FFFFH) to O(0000:fl). If the system clock is 12MHz, the timer interrupt is asserted after every 65536
 Introduction to Embedded Systems

microseconds (0.0655 seconds), if the counter is started with an initial count OOH. For generating a delay of l second,
the timer interrupt should be generated multiple times. If one timer interrupt generates 50000 microseconds, l 00 such
interrupts are required to generate a delay of 5 seconds. For generating a delay of 50000 microseconds, the timer should
be loaded with a count 65536 - 50000 15536 (3CBOH). The following assembly code illustrates the use of timer and
timer interrupts for implementing the binary counter requirement. Timer Ois used for this.
;######(##########1############################################(#####
;bin:ary_counter· imer. src
;Applica;tion :Implementing bihb.ry counter using Timer Intenupt
;'l'be. LEP is turned on when the port line is at' logi·~, 0
;Wiit:teft by 'Shibu K V.· Copyright (C) 2008 .
; #it##lt# #### # ######l####.######'ltf#######W##################U#fltf##J'lHf ..
ORG UOOOH ; · Re.set vector
;JMP 0050H ·; Jump to main ro.utine
ORG 0003H External Interrupt O ISR location
RETI Simply return. Do nothing
ORG'OOOBH ; Timer 0. Interrupt .ISR location
; The ISR will not fit in 8 bytes size.
; Hence it is implemented as separate routiQe
JMP ·TIMERO INTR '; Function :implementing Titner O routine
ORG Ob13H . ·.· ...,,,... . . Externaf Interrupt' 1 ISR location
.RETI Simply return. Do nothing
ORG OOlBH Timer ·1 Interrupt ISR locati()n•
RETI , '. Simply return. Do n_othlng
'ORG 0023H , Serial lnterrupt ISR location
RETI Simply return. Do nothing
ORG 0050H ; .,S_tart o.f Program Execution
MOV P2, #OFFH ; Turn off all LEDs
ORL IE, '#1000001DB; Enal::Jle Timer O Int~rrupt
ANL IE, #11100010B ; Disable all interrupts Except Timer 0
MOV .SP, #OBH Set stack at memory location 08H
MOV R7,#00H ; Set counter Register R7 to zero.
CLR TRO
;Load Timer O with count corresponding to 50000 microseconds
MOV TLO, #0B8H
MOV THO, #3CH
MOV RO, #100 ; Load The multiplier for the time delay
; Configure Timer Oas Timer in mode 1 (16 bit Timer)
MOV TMOD, #OOOOOOOlb
SETB TRO ; Start Timer 0
JMP $ ; Loop for ever
;####################################################################
Routine for handling Timer O Int~rr~pt
Checks whether the timer runs for gen~~ating the desired delay
If so display increment the binary cou~ter and display the count
Load Timer O Register and the multiplier for generating next-
; 5 seconds delay 1
If the dela:y generation i~ nb:t,qomplete (RO>O) simply return
#I#,,
; ## ## #### ## # #,### # ## ## # # ## 1' t'# ### ### ##{ ### ## ## # ## #### # ### # # # ## ~ ## ##
 Designing Embedded Systems with 8bit Microcontrollers-8051

It should be noted that the Timer OISR involves lot of activities including binary coupter increment and display and
hence the delay between the successive count display may not be exactly 5 seconds: The timer count can be adjusted to
take these operations into account or the displaying of the count can be moved to the main routine and synchronization
between main routine and ISR can be implemented through a flag. It is left to the readers as an exercise.

5.3.9 Serial Port

The standard 8051 supports a full duplex (simultaneous data transmission and reception), receive buff-
ered (supports the pipelining system of the reception of second byte before the previously received byte
is read from the receive buffer) standard serial interface for serial data transmission. The Special Func-
tion Register SBUF provides a common interface to both . serial reception. and transmission registers.
· The serial reception and transmission register exist physically as two separate registers but they are
accessed by a read/write to the SBUF register. The Serial communication module contains a Transmit
control unit and a Rec.eive 'control unit. The transmit control unit is responsible for handling the serial
data transmission and receive control unit is responsible for handling all serial data reception related
operations. The Serial Port can be operated in four different modes. The mode selection is configured by
setting or clearing the SM0 and SMI bits of the Special Function Register Serial Port Control SCON.
Serial Port Control Register (SCON) (SFR-98H) SCON is a bit addressable Special Function
Register holding the Serial Port Control related bits. The details of SCON bits are given below.

[§~2~-,ii~:§pp~J::::: ~;; ,=~tc;. · ·ir:ii§fdii~.:f:j§~it;it::;~:,·~§.¢.q#;~;;~:: ,,s~pN#i ,:,. ::.s~oN.:o....

;,,SMO ' SMl SM2 REN 1B8 RB8 TI RI

The following table explains the meaning and use of each bit in the SCON register.

SeriaJ port tp.()deselector Setsthnerial port operation mode

Mµlt,ipr~~fisdtcoiiuhuiiicati~~fi_ag · . ::~]"-{2, =. t:l3µ~gJ~ M.ultiprnce~sor comrriunica,tion

• .,~M~«:ri,Q:Ri~-~~Jy~J1liieioc~s~9rcomm',l.!l~cati9n
:•:.,'.f(t:J?i~i;,'·.;:J.r /?f:~:;~.--;"':::;;·i:rrt,/i C·

~,
1
t ,J;}~ta\~fttlt~(wm: 9~ tran~whted 1ll Modes 2 & 3.
· Settin:g/Gleiti'ing under software control
 Introduction to Embedded Systems

5.3.9.1 Serial Communication Modes As mentioned earlier, 8051 supports four different
modes of operation for Serial data communication. The mode is selected by the SM0 and SMl bits of
SCON register. The table given below gives the different combinations of SM0 and SMl and the serial
communication modes corresponding to it.

Mode O The Mode 0 operation of serial port is same as that of the operation of a clocked shift register.
In Mode Ooperation Pin RXD (Port Pin P3.0) is used for transmitting and receiving serial data and Pin
TXD (Port Pin P3 .1) outputs the shift clock. 8 data bits are transmitted in this mode with LSB first. The
baudrate* is fixed for this mode and it is 1/12 of the oscillator frequency. Mode 0 is half duplex, meaning
it supports only unidirectional communication at a time. It can be either transmission or reception. Serial
data transmission is initiated by a write access to the SBUF register (Any Instruction that uses SBUF
as the destination register. E.g. MOV SBUF, A; ANL SBUF, A; MOV SBUF, #data etc). The write to
SBUF loads a 1 to the MSB of the transmit shift register which acts as the stop bit in the serial transmis-
sion. The contents of SBUF register is shifted out to the RXD Pin in the order LSB first. The bit shifting
occurs in each machine cycle until all bits including the stop bit is shifted out. The bit shift rate is same
as the machine cycle rate and hence the transmission rate in mode 0 is 1112th of the oscillator frequency.
The Transmit Interrupt TI is set by the Transmit Control unit when all the 8 bits are shifted out. The TXD
pin outputs the transmit shift clock during data transmission. Serial data reception is enabled only when
the reception enable bit, REN is set 1 and the Receive Intenupt bit, RI is in the cleared state. A 'write
to SCON' (Clear RI/Set REN) initiates the data reception. The receive control unit samples the receive
pin, RXD during each machine cycle and places the sample at the LSB of the receive shift register and
left shifts the receive shift register. The Receive lntenupt (RI) is set when all the 8 data bits are received.
Pin TXD outputs the receive shift clock throughout the reception process.
Mode 1 In Mode 1, serial data pin TXD transmits the serial data and pin RX):\receives the serial
data. Mode 1 is a full duplex mode, meaning it supports simultaneous reception and transmission of
* Baudrate is defined as the number of bits per second.·
 Designing Embedded Systems with 8bit Microcontrollers-8051

serial data. 10 bits are transmitted or received in Mode l. The 10 bits are formed by the start bit, 8 data
bits and one stop bit. The stop bit on reception is moved to RB8 bit of SCON. The baudrate i~ variable
and it can be configured for different bauds. Similar to Mode 0, transmission is triggered by a write ac-
cess to the SBUF register in Mode 1. A 'write to SBUF' signal loads a 1, which acts as the stop bit, to
the 9th bit position of the transmit shift register apd informs the transmit control unit that a serial data
transmission is requested. Unlike Mode Owhere transmission is synchronized to 'write to SBUF' signal,
in Mode 1, the transmission is synchronized to a divide-by-16 counter. The divide-by-16 counter count
rate is dependent on the timer 1 overflow rate. The_ transmission starts with sending the start bit (logic
0), when the divide-by-16 counter rolls over
after the 'write to SBUF' signal. The transmit
register contents are shifted out to the TXD
pin (P3.1 Port pin) at the successive rollover
of the divide-by-16 counter. The Transmit
Interrupt TI is set by the transmit control unit t == 0 Time
when all the 8 bits are shifted out. Figure 5.31 (Fig. 5.31) Bi~ Tl'ansntii;sion w!th res})ect to time in Model
illustrates the bit transmission with respect to
time in Mode 1.
Serial data reception is triggered by a 1 to Otransition detected at the Receive pin RXD. The RXD
pin is sampled at a rate of 16 times the baudrate. On detecting a 1 to Otransition at the RXD pin, the di-
vided-by-16 counter is reset and 1FFH is loaded into the receive shift register. The divide-by-16 counter
divides the bit time of a bit (1/baudrate) into 16 time frames. In order to reduce noise in input data, the
RXD pin is sampled at 7th, 8th and 9th frames of the bit tiine. lf the value remains the same for at least
two of the samples, it is taken as the data bit. If the value obtained for the first bit time (start bit) is not 0,
the receiver circuitry resets and it will look for another 1 to Otransition as a valid start bit condition. On
receiving a valid start bit it is placed in the receive shift register at the rightmost position after shifting
the present contents of the receive shift register to the left by one. As data bits enter into the rightmost
position, the initially loaded 1s in the receive shift register is shifted out through the left most position.
As the reception goes on, when the start bit (the first received Obit) reaches at the left most position of
the receive shift register, the Receiver unit is informed that only one more bit reception is required and
to load the SBUF with the contents of receive shift register after the reception of next bit, move the next
receiving bit (stop bit) into RB8 and set the Receive Interrupt RI. The signal to load SBUF and RB8 and
set RI is generated only when Receive Interrupt RI = 0 and Bit SM2 in SCON is Oor received stop bit
1 at the time ofgeneration of the final shift pulse. If both of these conditions are not met, the received
byte is not moved into SBUF else the received byte is moved in~o SBUF, the received stop bit is placed
in the RB8 bit, present in the SCON register and the Receive Interrupt (RI) is activated. After the recep-
tion of the stop bit, irrespective of the above-mentioned meeting criteria, the receiver unit looks for the
next 1 to Otransition at the RXD pin for catching the next byte.
Baudrates for Mode 1 As mentioned earlier, the baudrate for Mode 1 is variable. Mode 1 baudrate is
dependent on the operating frequency and Timer 1 overflow rate. The bit transmission rate in mode 1 is
dependent on the divide-by-16 counter overflow rate. The count rate of divide-by-16 counter is depen-
dent on the timer 1 overflow rate. Depending on the value of the SMOD bit, the divide-by-16 counter
l is incremented directly on the overflow of Timer 1 or after the two consecutive overflow of the timer
f 1. If SMOD is 0, the divide-by-16 ommter is incremented only after two consecutive overflow of timer
r. If SMOD is 1, the divide-by-16 counter is incremented with the overflow of timer 1. The baudrate in
Mode 1 expressed as:
 Introduction to Embedded Systems

Baudrate = ((2SMOD) x Timer 1 Overflow rate)/(16 x 2)

For baudrate generation operations, Timer 1 interrupt should be disabled. It is advised to rim Timer 1
in the timer mode for baudrate generation operation. Normally Timer 1 is configured in Mode 2 (Auto
reload mode) for baudrate generation. In this case the equation will become
Baudrate = 2sMOD x fosc/((12 x [256-THl]) x 16 x 2)
(Timer 1 in mode 2 is incremented at each machine cycle. One machine cycle contains 12 clock periods
and so the timer 1 increment rate is fosc I 12. In Auto reload mode the timer counts fr?m Auto r~load
value to FF and then rolls over. The machine cycles counted in mode 2 for overflow is expressed as 256
Reload count= 256 THl (THl holds the auto reload count). Hence, Timer 1 overflow rate ·can be
_expressed as f0 s/(12 x [256-THl])
where
SMOD is the Baudrate multiplier bit present in PCON SFR
fosc is the oscillator frequency
THI is the Timer 1 Auto re-load value.
For achieving low baudrates, Timer 1 can be configured in Mode 1 to run as 16bit timer with interrupt
enabled. In Timer 1 interrupt handler write the code to re-load Timer 1 with the count required to get
the desired baudrate.
Theoretically the maximum baudrate that can be achieved with Timer 1 running in Mode 1 is given
as
Max baudrate = 2sMOD x f0 s/(12 x 16 x 2) _
Re-load Timer 1 with FFFFH in Timer 1 interrupt handler.
Minimum baudrate that can be achieved with Timer 1 running in Mode Us given as Min Baudrate==
2sMOD x fos/(12 x 16 x.2 x 65536).
There is no need of re-loading Timer 1
I
The commonly used baudrates for Mode 1 of serial communication, required oscillator frequency,
timer mode and Timer 1 reload value for auto reload mode of Timer 1 are tabulated below. Timer 1 is
assumed to be run in the timer mode (Not in counter mode) for all these calculations.

Mode 1 baudrate 9600 is the most compatible to communicate with PC's COM port.
 Designing Embedded Systems with 8bit Microcontrollers-8051

Modes 2 & 3 11 bits are transmitted in Modes 2 & 3. The 11 bits ar;fonned by the 8 data bits, 1 start
bit (0), 1 stop bit (1) and a programmable bit that acts as the 9th data bit. Mode 2 & 3 are also full duplex
and serial.data is transmitted through the pin TXD and reception is carried out through the pin RXD.
TB8 bit of SCON register is transmitted as the 9th bit. TB8 is programmable; it can be set to either 1 or
0. TB8 bit can be used as a parity bit for transmission. The parity bit of PSW reflects the parity of Ac- '
cumulator content. If the data byte to be sent is the Accumulator content, the parity bit of PSW can be
directly moved to TB8 bit of SCON for transmitting it as the 9th data bit, which will give the functional-
ity of a parity enabled serial data transmission. On reception of serial data, the 9th data bit is moved to
the RB8 bit of SCON register. If the serial reception is also parity enabled, RB8 can be used for checking
the parity of the received byte. The bits of the received byte can be XORed and the resulting bit can be
conipared to the received 9th bit (which is present in the RB8 bit of SCON) in finnware to check whether
the parity bi! matches with the parity of the received byte. This ensures error free reception of data. The
received stop bit is ignored in Modes 2 & 3. Mode 2 and Mode 3 of Serial communication is similar in
all respect except that the Mode 2 and Mode 3 baudrates are different.
Mode 2 baudrate is fixed and is given as 2sMOD x f0 s/64
Depending on the SMOD bit, it can be either f08/64 or f08/32
Mode 3 baudrate is same as that of Mode 1. Refer back to Mode 1 baudrate for details.
5.3.9.2 Multiprocessor/Controller Communication Support Multiprocessor/controller com-
munication implements communication between multiple processors/controllers connected to the same
· serial interface bus. Each processor is assigned an, addr_ess which is set in the finnware.
One of the processor/controller acts as the master controller and the other controllers act as slave
controllers (Fig. 5.32).

RXD
TXD
GND

(l?ig. 5.32) M~ltiprocessor comm.unica~io~ s.etup

Modes 2 & 3 of 8051 serial transmisskm supports multiprocessor communication if the SM2 bit pres-
ent in the SCON register is set for each controller. In Modes 2 & 3 operation, 9 data bits and a stop bit
are received. The received 9th data bit goes to the RB8 bit of SCON register. With SM2 set, the serial
port interrupt is activated on reception of the stop bit only if the received RB8 bit is 1. When the master
processor/controller wants to transmit a block of data to any one of the slave controllers, it sends out the
 Introduction to Embedded Systems

address byte of the slave controller, to which it wants to communicate. The 9th data bit that will be send-
ing along with the address byte will be 1. If the multiprocessor mode is enabled in slaves, on receiving
the address byte the receive interrupt is activated and each slave controller can use the interrupt handler
to examine whether the received address byte is matching to its assigned address (which is stored in the
firmware). If a slave finds that the received address byte is matching with its address, it clears its SM2
bit and waits to .receive the data byte block from the master. The data bytes are sent along with a 9th data
bit which is 0. If the 9th data bit is 1 it implies that the incoming byte is an address byte and if it is 0, it
informs the controller that the incoming bytes are data bytes. Once a slave is selected, it clears its SM2
bit and generates interrupt for all incoming data bytes while all other slaves ignore the received bytes
since their SM2 bit is still in lhe set condition. To enable the multiprocessor communication again in the
selected slave which is presently involved in the transmission it should be informed the end ofreception
of data bytes through· some mechanism. On receiving the end of data byte reception information, the
slave sets the SM2 bit and brings back the slave eontroller into multiprocessor communication enabled
mode. ·
Setting SM2 bit in Mode O will not produce any effect in transmission/reception. If SM2 is set in
Mode 1 the validity of the received stop bit is checked. If SM2 = 1. and Mode = 1, receive interrupt RI
is generated only if the received stop bit is 1.

Design an 8051 microcontroller based system for serial data communication with a PC as per the requirements given
below. ·
1. Use Atmel's AT89C51/52 or AT89S8252 (Flash microcontroller with In Systerp Programming (ISP) support) for
designing the system.
2. The baudrate for communication is 9600.
3. The serial data transmission fonnat is 1 Start bit, 8 data bits and 1 Stop bit.
4. The system echoes (sends back) the data byte received from the PC to the PC.
5. On receiving a data byte from the Serial port it is indicated through the flashing of an LED connected to a port
pm.
6. Use Maxim's MAX232 RS-232 level shifter IC for converting the TTL serial data signal to RS-232 compatible
voltage levels.
7. Use on-chip program memory for storing the program instructions.
8. Use the 'Hyper Tenninal' application provided by Windows Operating system for sending and receiving serial data
to and from the microcontroller.
The 8051 microcontroller has a built-in serial communication modµle which is capable of operating in different
modes with different data rates (baudrate). The only limitation is that the serial data is transmitted and received in either
TTL/CMOS logic. (The voltage levels are the one corresponding to logic O and logic 1 in the respective logic family.)
The serial communication supported by PC follows the RS-232 Serial communication standard and the voltage levels
are entirely different from the TTL/CMOS logic. The voltage levels for RS-232 is +/-12 V (We will discuss about the
RS-232 Protocol, voltage leve;l and electrical characteristics in a dedicated book, which is planned under this book se-
ries.) For translating the RS-232 voltage levels to the TTL/CMOS compatible voltage level, an RS-232 translator chip
is required between the PC interface and the microcontroller interface. The RS-232 translator chip is available from dif-
ferent chip manufacturers and the MAX232 IC from Maxim Dallas Semicon.ductors is a very popular level translator IC.
The Serial data is usually routed to an RS-232 connector (DB Connector). The RS-232 connector comes in two different
 Designing Embedded Systems with 8bit Microcontrollers-8051

pin counts namely; DB9- 9 Pin connector and DB25 - 25-Pin connector. For proper data communication, the Transmit
Pin of one device (Here either PC or microcontroller) should be connected to the receive pin of the other device and
vice versa. This can be done at the microcontroller board side by connecting the TXDOUT pin of MAX232 to the RX
(Receive)pin of DB connector and the RXDIN Pin of MAX232 to the TX (Transmit) pin ofDB9 connector. An RS-232
cable is used for connecting the PC COM Port with DB Connector of the microcontroller board. For the above configura-
tion, the RS-232 cable should be 1-1 wired meaning, the RXD and TXD lines of the connectors present at both ends are
1-1 connected. If the Serial lines are not used in the cross over mode in the microcontroller board, a twisted cable (cable
with RXD pin connected to TXD pin of the other end conne~tor and ~XD pin connected to RXD pin) can be used for
establishing the proper communication. The hardware connection for implementing the serial communication is given
in Fig. 5.33.

1N4007
+
--1 + O.lMFD ~ <
N < g 220MFD/ 0 (")
2
<~ 25V - (") (")

lMFD
O.IMFD I +

~ ~----,
00

IN4148/
-IN4007

(F+gr5.33) Serial communication circuit implementation using 8051

For implementing the serial data communication as 1 Start bit+ 8 Data bits+ I Stop bit with a data rate (baudrate)
of 9600, the serial port should be configured in mode 1. Timer 1 should be configured to run in auto reload mode (Mode
2) to generate the required baudrate. With an operating clock frequency of 11.0592 MHz, Timer 1 in mode 2 should be
reioaded with a count 0FDH for generating a baudrate of 9600 (Refer section Baudrates for Mode 1: for more details
on baudrate generation for serial communication in mode 1).
The flow chart given in Fig. 5.34 illustrates the firmware design for implementing serial data communication.
The firmware for Implementing Serial communication in 8051 Assembly language is given below.
 Introduction toEmbedded Systems

Main routine
start

1. Tum off LED connected at Pin P2.0

2. Initialise stack pointer

Configurations for generating 9600 Baud

1. Configure Timer 1 in Mode 2

2. Disable Timer 1 interrupt
3. Load Timer 1 reload count (OFDH)
4. Disable serial interrupt
5. Select Mode 1 for serial communication

I. Set reception enable 'REN'

2. Clear receive and transmit interrupt flag
3. Start Timer I

Read receive interrupt (RI) flag

1. Read the received data

2. Turn on LED to indicate data reception
3. Reset RI Flag
4. Transmit the received data back

Read transmit interrupt(fl) flag

NO

1. Tum off LED

2. Reset TI flag

( Fig. 5;34) Flow .c::hart for impl~tne~ting p61Uiig. bas~d

·••- .
serial c~inni111lickticn
. .
 Designing Embedded Systems with 8bit Microcontrollers-8051

;###########################1####################1###################
}'serial_polling. src
; Firmw.are for Implementing Serial Commuri.ica:tion with PC
;Wdtten by Shibu KV. Copyright (C) 2008
;#l####t##f#########l##############################I#################
ORG OOOOH Reset vector
JMP 0050H Jump to start of .main program
ORG 0003H External I~terrupt O ISR location
RETI Simply return, Do nothing
QRG OOOBH Timer O Interrupt IS~ locatt()n
RETI Simply return! Do. nothing .
ORG 0013H ; Extern~]: lnteti:upt l .;LSR lncation
RETI Simply return.· Do n6th±}1g;_ ·
· ORG 001BH Timer 1 Interrupt· ISR location
RETI Simply r:eturn. Do nq;t}hing:. , ::
. ORG 0023H ; ;;$e;ial ipterrupt. I13f{ Tocati.d~ .
RETI j s'iinply .retu~n. Do ;nothing .
i #####H##########H###U#H##i#########~######ft"############HH###,##
OR(i 0.050H ; s.ta,rt of main program .
SETB P2. 0 ; Tufo ':or:f data reception ind..fci!'.toreIJtD
. MOV S!', #088 ; "Set stack at memoty 16-'Eat'.i~rto:sH .
.\::LR .TRl · ·· ... .i Stop Timer .1 .
MOV TMOD, #OOlOOOOOB ; Set Timer 1 in Mode 2 (Autoreload)
CLR EA· Disable all inte·rr1=1pts
MOV, THI, #OFDH ; Reload count for Tj_mer 2
MOV Tt.1, #OFDH
;~Select Mode 1 for serial Communication
SMO 0, SMl 1, SM2 0
; Set REN
; TBS= 0, RBS 0, TI =0, RI =0
MOV SCON, #0101000QB
ANL PCON, #01111111B; Reset baudrate doubler bit
SETB TRl ; Start Timer 1
Read Receive Interrupt {RI) flag
; Check whether data reception occurred
; If not, loop till RI=l
RECEIVE:JNB RI, RECEIVE
; Data received
CLR P2.0 Turn ON LED to indicate data reception
; Read the received data
MOVA, SBUF
CLR RI ; Reset RI flag
MOV SBUF, A ; Transmit back the received data
Read Transmit Intenupt (TI) flag
; Check whether data transmission completed
; If not, wait till completion {loop till TI=1)
JNB TI, $
; Data Transmitted
SETB P2.0 Turn off Indicator LED
CLR TI ; Reset Transmit Interrupt flag
JMP RECEIVE ; Wait for next data to arrive
END ; END of Assembly Program
 Introduction to Embedded Systems
r
The finnware polls the serial interrupt flags and takes the corresponding actions when either the receive interrupt or
transmit interrupt flag is set. This approach is CPU-intensive and the CPU is dedicated for serial data communication.
Another approach in which the serial communication is handled is the interrupt based communication approach. The flow
chart given in Fig. 5.35 models the interrupt based serial communication. ·

Main routine Serial interrupt

start handler

l. Tum off LED connected at Pin P2.0

2. Initialise stack pointer

Configurations for generating 9600 Baud

1. Configure Timer 1 in mode 2 Receive Interrupt Handling
2. Disable timer l interrupt NO
3. Load timer l reload count (OFDH) 1. Read the received data
4. Enable serial interrupt 2. Tum on LED to indicate data reception
5. Select mode 1 for serial communication 3. Reset RI flag
4. Transmit the received data back

1. Set reception enable 'REN' Transmit Interrupt Handling

2. Clear receive and transmit interrupt flags l. Tum off LED
3. Start timer 1 2. _Reset TI flag

Perform other tasks or simply wait forever Return

The finnware implementation for the interrupt based serial data communication is given below.

;serial_interrupt.src
; Firmware for Implementing_ Serial Communication with PC
;Serial Data reception and transmission handled through Inter:i;-upts
;Written by Shibu K v,. Copyright .(C) 2QQa.
; #############t####U#####O#)tHJ,######,~###-U###fH#####UU##U~hHt##
ORG OOOOH Reset vector
JMP 0050H ; Jump to_ start of .Jnain Toutine
ORG 0003H , . External ·rnt.errupt.tO 1'SR.location
·RETI s.L~plYc,re,tiJ;r:fi}i,O~•-.. nqtr1ing
ORG OOOBH ; Tirrre,r;~o'.rnf~r±upMrsR i,ocation ..
RETI , sint~~y: 1{~}fofr\i)?'i/:~9thing -.. , ·_ .. .,
ORG 0013H -, Extc~tpal .•Jriter~ptl J · ISR .loca doh
RETI Siinpty<retLff:o.•'.•pb I}Pth;L4g·.
ORG OOlBH Timer ·1 In\.~rit:µ~tISW'lcfoatioh
RETI s'±mply fettlrb:·Lf.)9 rr6tliihg .
· ORG 0023H Se:i;ial Interrupt.: I.SR location .
; ·1nte.frupt ·h_andling::w{N.nbt··.fitt,_£n~.:',byt~s
 Designing Embedded Systems with 8bit Microcontrollers-8051

; Call the routine where interrupt is handled

CALL SERIAL INTERRUPT
.RETI ; Return
;#########t##############################f#f##I######################
ORG 0050H Start of main Program
SETB P2.0 Turn off data reception indicator LED
MOV Sf,#08H Set stack at memory location 08H
CLR Stop Timer 1
MOV TMOD, #00l00000B; Set Timer 1 in Mod~ 2 JA.utoreload)
MOV IE, ·110010000B ; ·Enable only serii:1.l interrupt
MOV THl, #cfFDH ; Reload count for Timer 2
MOV TLl, #0FDH
Select Model for serial Coffi!l)unication
; SM0 = 0, SMl = 1, SM2 - 0.
; REN= 1, TB8 0, RB8 = 0, TI 0, RI 0
MOV SCON, #01010000B
ANL PCON, #01 lllB ; . Reset baudrate-·doubler bit
SETB TRl ; Start iimer 1
JMP $ ; Simply Loop here
#f#####f#############t####t#####t#ef~###########~####i#####f###flt###
;Routine for handling Serial Interrupt (Both RI & TI)
;Only one Interrupt available for T~ansmissipn and Reception
;Check whether the interrupt is or RI
· ;Perform 'the actions· corr~sponding to the Interrupt and then Return
: ; ########f#U####H######################U#i########f###f######'#####
SERIAL INTERRUPT:
; Check whether the interrupt is Receive Interrupt (RI)
JNB RI, CHECK TI
; Receive Interrupt occurred
; Data received
CLR P2.0 Turn ON LED to indicate data reception
MOV SBUF Read the recelved data
CLR RI Reset RI flag
MOV SBUF, A Transmit back the received data
; Receive Interrupt process completed
; Return
RET
CHECK TI:
; Transmit Interrupt occurred
; Data Transmitted
SETB P2.0 ; Turn off Indicator LED
CLR TI ; Reset Transmit Interrupt flag
; Transmit Interrupt processing completed
; Return
RET
END ;END of Assembly Program
This design will not be complete without explaining the PC side application responsible for sending and receiving se-
rial data to and from the 8051 based system connected to the serial port (Communication Port 1, COM 1) of the PC. The
8051 based system should be connected tq _the serial port using one of the cables (twisted/ one-to-one), as per the design
requirement, as explained earlier. Figure 5.36 illustrates the interfacing of the microcontroller board to the COM port of
the PC.
■
,,--r--~,-,' I
.
Introduction to Embedded Systems

DB-9 COM connector

{:)

RS-232 Cable

The Microsoft® Windows Operating System (Windows 9x/XP is used in our example) provides a built-in serial com-
munication terminal program called 'Hyper terminal'. The 'Hyper\terminal' application can be launched through Start
➔ All Programs ➔ Accessories ➔ Communications ➔ Hyper terminal
The Hyper terminal application will r~quest,for a Connection Description while launching a new instance of the ap-
plication. Provide a connection description name (say 8051) in the Connection Description wizard. Discard the Connect
To wizard by Cancel. Select Properties tab from the File menu of the Hyper terminal application. ~new window describ-
ing the Properties of.the Hyper terminal conrtection is displayed. From the Connect To tab of the new Window, select
the com number to wh!ch the 8051 system is connected, say COMl,_against the Connect using: option. Now select the
Configure .. button. A new configuration window is displayed for configuring the Port Settings for the selected COM port.
Configure the Bit per second: to 9600, Data bits: to 8, Parity: to None, Stop bits: to 1 and Flow control: to None. Save
the Port Settings through the Appjy button. Exit the Port Settings window by invoking the OK button. Start the communi-
cation by invoking the Call option from the Call menu (This can also be achieved by pressing the Telephone icon on the
hyper terminal window). Now you are ready to communicate with the 8051 system connected to the communication port
configured as per the requirement. Start sending data by typing on the hyper terminal application. You can see the data
echoed by the 8051 system on the hyper terminal application. The hyper terminal application can be stopped by invoking
the Disconnect option from the Call menu. (This can also be achieved by pressing the Telephone Hang-up icon on the
hyper terminal window.)

5.3.10 ResefCircuitry
Reset is necessary to bring the different internal register values and associated internal hardware cir-
cuitry to a known state. Before. putting the 805.1 controller into operation a reset should be applied to the
controller. As mentioned earlier, applying a reset loads the registers with default known values and loads
the Program Counter (PC) with 0000H. This ensures that the program execution starts from the start of
the code memory (0000H) and stack will reset to the memory location 07H. Reset can be of two types:
hardware and software reset. Hardware reset brings all associated hardware units to a well-defined ini-
tiarstate. 8051 provides a pin named RST for applying the hardware reset.
The reset signal must be kept active until all the three of the following conditions are met
1. The power supply must be in the specified range .
.2. T~e oscillator must reach a minimum oscillation 1level to ensure a good noise to signal ratio and a
cprrect internal duty cycle generation. i '
3. The reset pulse width duration must be at least two machine cycles (24 Clock periods) when con-
ditions 1 and 2 are met.
 Designing Embedded Systems with 8bit Microcontrollers-8051

If one of the conditions is not satisfied, the microcontroller may not startup properly. To ensure a
good startup, the reset pulse width has to be wide enough to cover the period of time, where the elec-
trical conditions are not met. Please refer to the note given on the 'On line Leaming Centre', on the
important parameters that should be taken into account for determining the reset pulse width.
The C5 l family of microcontrollers support two kinds of reset input. The first one is a pure input
which allows an external device or circuitry to reset the mi- ·
crocontroller. The second one is bidirectional, in which the
microcontroller is capable of resetting an external device. Capacitor
In actual practice a power on reset (unidirectional input) lOMFD
is given to the 8051 controller by connecting an external
resistor and capacitor as shown in Fig. 5.37.
When the power supply is turned on, initially the capaci- Resistor
tor acts as short circuit and the full applied voltage appears 8.2K
across the resistor (RST pin becomes at logic 1). The ca-
pacitor starts charging gradually and the applied voltage
is build across the capacitor (RST pin becomes at logic 0).
The time taken by the capacitor to get charged to a voltage
VC, which brings the RST pin to logic LOW, is calculated f~J§,~?) ~.P,~i!~#:~hi~~~f.!~~~~~t.~~f.-"~~~r.
as
V = V - (V - V) x e-tlRC
C f f 1
VC = voltage at which RST pin logic high changes to LOW
Vr= final voltage (VDD =5 V)
VI initial voltage (=0 V)
RC= time constant ofresistor capacitor circuit (8.2 x 10 3 x 10 x lQ-6)
The reset pulse width 't' can be calculated from the above equation with Ve= The voltage across RST
pin which makes the RST pin at logic 0 and Vr= 5V. The pulse width will be of the order of milliseconds
to seconds. This ensures that the RST pin remains HIGH for enough time to allow the oscillator to start
up (A few milliseconds), the power supply to stabilise plus two machine cycles. It is to be noted that the
port pins will be in a random state until the oscillator is started and the internal reset algorithm writes 1
to the corresponding port SFRs.

5.3.11 Power Saving Modes

I For applications like battery operated systems where power consumption is critical, the CMOS version
of 8051 provides power reduced modes of operation namely IDLE and POWER DOWN modes.

Ii S.3.11.1 IDLE Mode The IDLE mode is activated by setting the bit PCON.0 of the SFR power
control register (PCON). The instruction setting the PCON.0 bit pushes the processor into an idle state
where the internal clock to the processor is temporarily suspended. Before putting the CPU into idle
state, the various CPU statuses like Stack Pointer (SP), Program Counter (PC), Program Status Wor.d
1
(PSW) and Accumulator and all other register values are preserved as such. All port pins will hold the
.1 logical states they had at the moment at which the idle mode is activated by setting the PCON.0J.1_it.
ALE and PSEN remains at logic high during Idle Mode. The interrupt, Timer and Serial port sections
continue functioning since the clock signal is not withdrawn for the same. The Idle mode is terminated
by asserting any enabled interrupt. The interrupt can be any one of the external interrupt (INTO or INTl)
~or Serial Interrupt. On. a&_serting the interrupt, the IDL bit (PCON.O) is cleared and the interrupt routine
 Introduction to Embedded Systems

is serviced. After executing the RETI instruction, the next instruction executing will be the instruction
which follows immediately the instruction that put the processor in Idle Mode. Two general purpose
flag bits GF0 & GFl present in the PCON register can be used for giving an indication for whether an
interrupt occurred in normal mode or Idle Mode. Since PCON register is not a bit addressable register,
the instruction which sets the IDLE Mode control bit PCON.0 can also set the flags either GF0 or GFl
or both. When an interrupt occurs its service routine can examine whether the interrupt occurred in the
Idle mode or Normal mode by checking the status of GF0 or GFl bits of PCON (valid only if the Idle
mode enabling instruction sets the GF0/GFl bit along with PCON.0).
The second method for terminating the idle mode is the application of a reset input signal at the RST
pin. Since the clock oscillator is already running and it is in the stable state, the RST pin need to be held
high for only 2 machine cycles. Resetting the processor clears the IDL bit (PCON.0) directly and at this V
point the processor resumes program execution from where it left off, that is, at the instruction which n
immediately follows the one that invoked the idle mode. When the internal circuitry undergoes the reset C

algorithm follpwing the Reset, two or three machine cycles of program execution may take place. The n
On-chip hardware inhibits any read/write access to the scratchpad RAM during the internal reset algo- a1
rithm execution, but access to the port pins are not inhibited. Hence it is advised to put a minimum of 3 k
NOP instructions which follows the instruction that triggers the idle mode. lS
rt
Power Control Register (PCON) (SFR-81H) It is the Special Function Register holding the power
control bits and baudrate multiplier bit. PCON is not a bit addressable register. The details of PCON bits S.
are given below. re
Je
1
~:~ttt' :xt@}~ SU
SMOD R.SD . ' eJi
re
j The following table explains the meaning and use of each bit in the PCON register. ill
m

qu
qu
:!::
• , , "/:.· ·.,';·--:~>"({ _~·r:. ,, "/ }''"'·;;,.t:•:r~?:~r'..-.;/t-~;riz::.·.:y;,>7;:o;:_ f.' ,.V'"
ry
GFl General purpose flag bit 1 User programmable bit Can be set or reset under ffnnware control · • · .. ·. · co
rGFQ\. · ~;de···~····:·:·~ffiri. 1}.P.\irp6····s··'·e· :fti}g·bt.t_,.o, ,IJ;bfp}~gta. ,
. , ·• ••• •• _ _ , , ___ . ., ,• ; .P.X>.~•''•"~' h'o,, A_;·,,"-<
hit.Ji4ti]};~~filift~i~i*'• .
.~ .,.,:•_--;_ ,.,,_.,.,'', .... , •• ,~~-♦ -;.,t;,,,.,il-·;,J:•
. Fn
PD Power down control bit PD =.1 InvoJces power down mode. Sp(

r;int,:,· · : tiilli~~aecontrofb,if' .: ;::1nt'¼J~vok~iafl.wo8l'?r,: :;/::::r,\, 1 hif

po·
The NMOS version of 8051 devices implement only SMOD bit in PCON register. The other 4 bits dei
are available only in CMOS versions. Reset value of PCON is 0XXX0000 (X denotes don't care. It may mg
be either 0 or 1). PD bit always take precedence over IDL bit and if an instruction sets both IDL and PD lea
bits to 1, action corresponding to PD= 1 is performed and it masks the IDL bits activity.
Hi!
S. 3.11.2 Power Down Mode When the PD bit (PCON. l) is set by an instruction, the Power Down on
mode is activated. The CPU stops executing instructions; clock signal to all internal hardware including eye
timer unit, intenupt system and CPU is terminated. The contents of internal RAM and SFR are main- clo1
tained. All ports continue emitting their respective SFR contents. ALE and PSEN signals are held at low. ope
Power Down mode can only lre term_inated through hardware reset All SFRs are brou~ht into their w~et
 Designing Embedded Systems with 8bit Microcontrollers-8051

JlJlfL To interrupt control,

Clock signal timer & serial port unit

To CPU

PD IDL

values. How~ver the on-chip RAM retains their contents to that of the values when the Power Down
mode
.
is entered. The supply voltage.Vcc to the controller can be brought down to as low as 2V when the
controller is in Power Down mode. However before te_rminating the Power Down mode with a hardware
reset,. the supply voltage Vcc should be brought into the normal operating level. If the hardware reset is
applied to the controller to terminate the processor before bringing the operating voltage to the nominal
level, the controller may behave .
in an unexpected way. Hence reset should not be activated before V.
. ~

is brought to its normal operating level, and the reset signal should be held active till the oscillator is
re-started and becomes stabilised.
5.3.11.3 Power Consumption Vis Oscillator Frequency Average Power consumption is di-
rectly proportional to the operating frequency (Clock frequency). Increasing the clock frequency"(sub-
ject to the condition that it will not exceed the maximum ·~
supported frequency by the system core) increases the Typical 80511cc
execution speed of the controller. But it also has a. di- vs. Frequency characteriStics
25
rect i~pact on the total power consumption. Figure 5.39
illustrates the typical power curve for a generic 8051 ,--, /!/
microcontroller. @
'-'
20 /
.Generally, the current consumption v/s operating fre- §
quency characteristics is linear with a de offset. The de ·11s /v
/
///

quiescent current is generated by static on-chip circuit- ~

E /
ry such as op amps, comparators, etc .. This current is a 8 10
constant drain current typically in the range of lmA. i::V · · vv
/
From the power curve it is obvious that as the operating ~ 5 /

speed demand is high, the power consumption also goes u / /

high. So there is always a trade-off between processing 0

power and power consumption with the generic 8051 I 2 3 4 5 6 7 8 9 1011!21314151617181920

I design. Some techniques used to achieve high process-

ing speeds by maintaining the power consumption to the
least possible are explained below.
Operating frequency (MHz)

(Fig. 5.39) Typiccll,Pow~r cons1;1mption curve

for generic 8051
High-speed core The original .8051 design was based CopyrightM~im Integrated P.r,oducts ··
(http://~maxim:ic.com) used by permis-
on a 12 clock/machine cycle and two fetches per machine sion
cycle architecture. The high speed core uses 4 clocks or 1
clock per machine cycle design.·Comparing this with the original 12 clock/machine cycle for the same
operating frequency, the performance will be approximately 3 times for the 4 clock core and 12 times

I
 Introduction to Embedded Systems

for the 1 clock core preserving the same power consump-

tion. Figure 5.40 gives a comparative measure of power Relative power consumption
25
consumption for 80C3 l and 80C32 core based on 12 clock/ /
machine cycle and Maxim/Dallas' DS80C320 core based 1//
20
on 4 clock/machine cycle design. V
80C32
/ / 80C31
Use of Single Chip with integrated peripherals A ' r'i. /
.,,,,
" .. 1,/"
typical 8051 microcontroller based embedded system in- /
/ .,,,.,,,
corporates a n!,lmber of peripherals ranging from external u V .,,.v
8 10 ., . .,,..,,. ..,I""
UART to reset ICs (e.g. DS1232 from Maxim Integrated / 1,,/ ~"'~
/ ),... .,,..,,.
_Products/Dallas Semiconductor), brown-out circuits and ,.. /,... I,.;'__.
"
watch dog timers. Using these chips as separate ICs will 5
~v .... .,,. ., DS80C320
..... ~
definitely increase the total system power consumption. An ~~
0
111111
effective way of reducing this kind of power consumption 1 2 3 4 5 6 7 8 9 1011121314151617181920
is the use of a single chip that integrates the 8051 controller Performance relative to 1MHz 8051
and the related necessary chips in a single chip. Apart from
significant reduction in power consumption, this approach
also reduces the space required for placing the components
on the PCB and thereby makes the embedded product much
more compact one.
Use of On-chip program memory and RAM Use
of external Program Memory (EEPROM/FLASH) and RAM requires an additioncJ,l latch circuit (e.g.
74LS373) to latch the lower order address bus from the multiplexed address/data bus. Adding this chip
will again increase the total system power. Nowadays controllers with internal program memory rang-
ing from 4K to 64K are available in the market. Some manufacturers provide extra RAM up-to 1 KB as
on-chip RAM.
Waveform vs. Ice Comparison
Clock source The standard 8051 design uses either an ex-
ternal quartz crystal resonator to excite the internal on-chip
oscillator circuitry or an external standalone crystal oscillator.
If an external crystal oscillator is used, the waveform of the
clock can affect power consumption. The input stage of the < 15· 1---+----.----+....,,,.,,,,r--+-----i
XTALl pin, used for driving the external clock signals into s
'-'
u
the 8051, typically employs complementary drivers. As the ...;f 10 f--~+->49'-+.- Square
input clock transitions between high and low, the drivers will I
momentarily both be ON, causing a significant current rush.
·_ With a square wave clock signal, the transition between high
and low is almost instantaneous and the time in which both 0 '---~------'---------"
I 5 10 15 20
drivers are ON is minimised. A waveform with a slower rise
Frequency (MHz)
and fall time, such as a sine or triangle wave, will take long r
time to complete the transition and both drivers will be on ( Fig.5.41) Po~e~ c9nsu~~tj.on ~rve for r
for a long time. This will increase the current and power con- differenttld~k v.tave~ . 1
CopJ,tfghiM'axim1ntegra.ted Products
sumption. A comparison diagram for power consumption for C
(http://w:ww.ma.:eim-ic.com). use.d by
different clock 1.vaves is given in Fig. 5.41. permission. r
n
I
 Designing Embedded Systems with 8bit Microcontrollers-8051

S.3.1 J.4 On Circuit Emulation (ONCE) Mode The On Circuit Emulation (ONCE) Mode helps
in testing and debugging the system without removing the microcontroller from the circuit. The ONCE
mode is invoked through the following steps:
1. Pulling the ALE pin while the controller is in reset and PSEN is high
2. Holding the ALE pin low as Reset is de-activated
In ONCE mode, Port Opins stay in the floating state and other Port pins, ALE and PSEN are pulled
high weakly internally. The oscillator circuit remains active. With these conditions an emulator or an-
other controller can be used for driving the circuit. Normal operation of the target controller can be
restored by applying a normal reset.

The 8052 microcontroller is a member of the 8051 family and it c,an be considered as the 'big' brother
of 8051. 8052 is pin to pin compatible with the standard 8051 microcontroller. The only difference be-
tween the 8051 and 8052 is that 8052 contains certain additional functionalities. The 8052 architecture
implements the upper 128 bytes of user data RAM physically on the chip and application programmers
can access this memory through indirect addressing, whereas the standard 8051 architecture doesn't
implement the upper 128 bytes of data RAM physically on the chip. 8052 also implements an additional
16bit timer (Timer 2) and thus the total number of timers available in 8052 is three, whereas the standard
8051 architecture impleme°:ts only two timers. T2CON is the SFR register implemented in 8052 for
controlling the timer 2 operations. The 16bit timer register is formed by the register pair TH2 and TL2.
Timer 2 supports interrupt and the interrupt vector location for Timer 2 is 002BH. Timer 2 supports a
special mode of operation called 'Capture Mode' and when the timer is in capture mode the contents of
TH2 and TL2 is captured to the capture SFR RCAP2H and RCAP2L respectively when a 1 to Otransi-
tion is detected at the Pl.I pin of the microcontroller. The timer 2 interrupt is also generated if the timer
2 interrupt is in the enabled state.

Lot of variants are available for the basic 8051 architecture from different microcontroller manufactures
including Atmel, Maxim/Dallas, etc. We will have a glance through on some of them.

5.5.1 Atmel's AT89C51RD2/ED2

I
The AT89C51RD2 from Atmel Corporation is a high speed 8052 core compatible microcontroller. It
contains six 8bit I/O ports, three 16bit Timers/Counters, 25 6 bytes of user data RAM, 9 interrupt sources
with 4 levels of priority and 64 Kbytes of on-chip In System Programmable FLASH memory for pro-
(
gram storage. It also contains 1792 bytes of on-chip expanded RAM (XRAM), SPI port, pulse width
modulation (PWM) unit, integrated watch dog timer (WDT), integrated power monitor for Power On
reset and power supply fail detect, dual full duplex serial port and dual Data Pointer Register (DPTR).
The 89C51RD2 controller can be operated in standard mode and high-speed mode. The standard mode
of operation requires 12 clocks per machine cycle, whereas the ~igh-speed mode (Also known as X2
mode) requires only 6 clock periods per machine cycle for instruction fetch and execution. Standard
mode supports clock speed ofup to 60 MHz and high speed mode supports dock speed up to 30 MHz.
It also supports variable length MOVX instruction for synchronising the data communication with
 Introduction to Embedded Systems

slow RAM/peripheral devices. It also contains 2Kbytes of FLASH bootloader containing the low level
FLASH memory programming routines and default serial loader. The 89C51ED2 version is similar to
the RD2 version in all respect and it supports 2Kbytes of On-Chip EEPROM memory for non-volatile
data storage.

5.5.2 Maxim/Dallas' DS80C320/ DS80C323

The DS80C320/DS80C323 microcontrollers from Maxim/Dallas are high speed low power microcon-
troller~ compati~le with the standard 80C3 J/80C32 architecture. It contains four 8bit VO ports, three
'
16bit timers/co~nters, 256 bytes of user data RAM, 13 total interrupt sources with six external, with 3
levels of priority, programmable watch dog timer (WDT), integrated power monitor for Power On reset
and power supply.fail detect and dual Data Pointer Register (DPTR). The high speed core of DS80C320/
DS80C323 uses 4 clocks or 1 clock per machine cycle design. Comparing this with the original 12
clock/machin~ cycle for the same operating frequency, the performance will be approximately 3 times
for the 4 clock core and 12 times for the 1 clock core preserving the same power consumption.

Summary
✓ Fe~ture ,set, speed of operation, code memory space;·data memory space, development suppo(ti '{i.vailability,
power~oti~unipfibn,;c~st, etc, are the important factors that heed.to,be considered in the selectio~, of{miqoc<,ma
troller foran,eillbedded;design . . I
. v The j)~sk 8051 architectur~ consist of an 8bit CPU .with Boolean pro~essing q1pability, qscillatordriv~r:'w1H,, ·
4K bytes of on,-chip program memory, 128 bytes of internal data memory, 128 bytes 9f ~pecial fundion register .
me'~~ryare.a,J2general purpg~e I/() lines orga~i~ed into four 8bit bi,.directionaiports,.cy.,o '16bit titner·units arid
a full duplex programmable UART for serial data transmission with configurable bm1,drates . ·· · _ · ·
✓ 8051 is built around the 'Harvard' processor architecture. The program and data rhemory bf 8051 is'logically
separated and they physically reside separately. Separate address spaces a:re assigned for data memory and pro-
. gram memory. 8051 's address bus is 16bit wide and it can address up to 64KB ;memory
✓ The Program Strobe Enable (PSEN) signal is activated during the external program memory fetching operation,
whereas.it is not activated if the program memory is internal to the microcontroller. The Program Counter (PC)
Register supplies the address from which.the program instruction to be fetched.
✓ The 8051 architecture implements 8 general purpose registers with names RO to R7 and they are available in 4
different banks
✓ The lower 128 byte RAM of 8051 is organised into register banks, Bit addressable memory and Scratchpad RAM
✓ Accumulator, B register, Program Statu~Word (PSW), Stack pointer (SP), Data pointer (DPTR, combination of
DPL and DPH), and. Program Counter (PC) constitute the CPU registers of 8051
✓ The instruction fetch operation consists of a number of machine cycles and one machine cycle consists of 12
clock periods for the standard 8051 architecture
✓ 8051 supports 4 bi-directional ports. The ports are named as Port 0, 1, 2 and 3. Each port contains 8 bidirectional
port pins
✓ The 'Read Latch' operation for all port pins return the content of the corresponding pin's latch, whereas the 'Read
Pin' operation returns the status of the port pin
✓ The basic 8051 and its ROMless counterpart 8031AH supports five intemiptsources; namely two external inter-
rupts, two timer interrupts and the serial interrupt. The serial interrupt is an ORed combination of the two serial
interrupts; Receive Interrupt (RI) and Transmit Interrupt (TI). An interrupt vector is assigned to each interrupts
in the program memory and 8 bytes of code memory location is allocated for writing the ISR corresponding to
each interrupt
 Designing Embedded Systems with 8bit Microcontrollers-8051

✓ The int~rrupt system of 8051 can be enabled or disabled totally under software control by setting or clearing the
globalinterrupt enable bit of the Special Function Register Interrupt Enable (IE).
✓ The· 8051 architecture s'upports two levels of interrupt priority. The first p{iority level is determined by the
settings of the Interrupt Priority (IP) register. The second level is dete1U1ined by the internal hardware pollir1,g
sequence
✓ An interrupt service routine always ends with the instruction RETI. The RETJ instruction informs the interrupt
system that theservi~ routine for the correspondingin(erru~t is finished and it ciears the corresp9nding'prioiity-
X interrupt fu pfogtessflag by clearing the corresponcling'llip fl6p ' . .· , ,, ·"' . . . .. ·.
✓ Thebasic 8()51 wchite9ture supports two timer units namely Timer Oand Timer 1. The timer units can be coiilig..: ·,
. ured to ope;at,e aieJtl¥r timer orCoimter. Th~'trme~s suppqrlfour ~od~sofoper~tion namely ¥bd~{q,'1}riiid\
a
✓ Tlw ~tt,11d,µ-(i ~05/;j~pppi;ts fuU duplex, receiye QlJffo,reg seri"l i~teif,a9e ,for ,serial data tra11snrissioi;t,, .·· . ,.·.· / ·.· ..
The :cM'.o's versi~ti'of\8051 supports hvo pow~~ tlowri modes, i{a111e1y;·inLE and POWER1i6WW'·T~~/itre
activ<1ted by ~yttwgtlje corresp9nding bitit1- SptecialFun.ction 1-legister PCON . .. . . . .•:
✓ Th~ oA circtiit emulaticirt (ONCE) mode of80.5lhelps in t~sti~gand debuggirig the 8051 mic;ocontrolle~ ~a~~~
system withoutre1:9Jwirigthrll:\icrq~ori.troller from th~circµH .·. • · · ·.·. . · . · ·. . . , : ·. ",.· :;:
. ✓ The,805 2 micro9ontrqilera:rchitecturejµpp9rts an additional 16bit ti~er and it supports captur~ 111oae fo} tiipir
operation ~n ,additi~n to the four modes supported by 8051. If also implefuents the upper US&yte{of u~~~'~ta
RAM physically oh the chip . · " .... •·

MIPS Million instructiQns per $ecqnd-;\ Q1easure oJ processor speed

Microcontroller Ahighlyin:tegrated chip thatcontains aCPU, scratch pad RAM, Special and General purpose
register Arrays and Integrated peripherals
Code Memory Memory for storing program instructions
Data Memory : Memory for holding temporary data during program exec\{tion
Register Data holding unit made up of flip-1}.ops
On-Chip Memory Memory internal to the microcontroller
Port An I/0 unit which groups a number of I/0 pins together and provides a control/status
register for controlling the I/0 pins and.monitoring the pin status
ALE : Address latch enable. A control signal generated by the processor/controller for indicat-
ing the anival of valid address signal on the address/data multiplexed bus
Program Counter CPU register which holds the address ofthe program memory location from which the next
instruction is to be fetched (Its width depends on the processor architecture)
Data Pointer Register 16bit register which holds the address of external data memory address to be accessed,
(DPTR) in 8051 architecture
Special Function Register : Register holding the status and control information and data associated with the various
configurations, status and data for on-chip peripheral units like Timer, Intenupt Con-
troller, etc.
Accumulator CPU register which holds the results- of all CPU related arithmetic operations
B Register CPU register that acts as an operand in multiply and division operations, in 8051 archi-
tecture
, 'Program Status Word 8bit, bit addressable special function register signalling the status of accumulator
, '(PSW) related operations and register bank selector for the scratchpad registers RO to R7, in
8051 architecture
Stack Pointer (SP) : 8bit register holding the cmTent address of stack memory in 8051 architecture
 Introduction to Embedded Systems

: · · 9tion execution. n 9tjon ~x~cution<i:nay require

nder standard 8 "' e:;'bnertiichig~'i;ycle cor-
F t·S.:~}:> '.' ,<,~,~ f: .,:. :·'., ~\ ,_::;~_;<\<:t? )· '<,'.>•,: \) ~- '

irj¢anJ~PPM .·' Jihepteditlevice

in~Bsot"'" ,' . ''6t~dt6~6xternal

Objective Questions
1. What is the size of internal data memory supported by the standard 8051 architecture
(a) 64bytes (b) 128bytes (c) 256bytes (d) 1024 bytes
(e) No internal data memory
2. What is the size of a 'Special Function Register' memory supported by the standard 8051 architecture
(a) 64bytes (b) 128bytes (c) 256bytes (d) 1024bytes
(e) No internal SFR memory
3. What is the size of an internal program memory supported by the standard 8051 architecture
(a) 128 bytes (b) 1024 bytes (c) 2 Kbytes (d) 4 Kbytes
(e) No internal program memory
4. What is the number of general purpose 1/0 lines supported by the standard 8051 architecture
(a) 8 (b) 16 (c) 32 (d) 64
5. The general purpose I/0 lines of a standard 8051 is grouped into
(a) Two 8-bit bi-directional ports (b) Four 8-bit bi-directional ports
(c) Two 16-bit bi-directional ports (d) Four 16-bit bi-directional ports
6. What is the number oftimer units supported by a standard 8051 architecture
(a) Two 16-bit timers (b) Three I 6-bit timers (c) Two 8-bit timers (d) One 16-bit timer
7. The UART of the standard 8051 controller is
(a) Half duplex with configurable baudrate (b) Half duplex with fixed baudrate
(c) Full duplex with configurable baudrate (d) Full duplex with fixed baudrate
8. The standard 8051 controller is built around
(a) Harvard Architecture (b) Von Neumann Architecture (c) None of these
9. Which of the following is True for a 8051 controller?
(a) The program and data memory of 8051 is logically separated
 Designing Embedded Systems with 8bit Microcontrollers-8051

(b) The program and data memory of 8051 physically resides separately.
., (c) Separate address spaces are assigned for data memory and program memory
(d) All of these (e) None of these
10. The address bus of 8051 is
(a) 8-bit wide (b) 16-bit wide (c) 32-bit wide (d) 20-bit wide
11. Which of the following is 'True about external program memory access?
(a) Port 0 acts as the data bus and Port 2 acts as the higher order address bus
(b} Port 2 acts as the data bus and Port 0 acts as the higher order address bus
(c) Port 0 acts as the multiplexed address/data bus and Port 2 acts as the higher order address bus
(d} Port 2 acts as the multiplexed address/data bus and Port 0 acts as the higher order address bus
12. Name the register holding the address of the memory·location,holding the next instruction to fetch
(a} DPTR (b} PC (c} SP (d} None of these
13. Name the register: holding the address of the ~xternal data memory to be accessed in.16bit external data memory
operation
(a) DPTR (b) PC . (c) SP (d} None of these
14. For standard 8051 architecture, the inte~al data memory address is
(a} 8bitwide (b} 4bitwide (c) 16bitwide (d} Noneofthese
15. The external data memory is 4 Kbytes in size and it is arranged in paged addressing mode where 1 page consists
of 256 bytes. Port 2 is used as the page selector. How many port bits are required for implementing the paging?
(a) 1 (b} ~ (c) 3 (d) 4
16. Which of the following conditions.should be satisfied to implement the Von-Neumann memory model for 8051?
(a} The data memory and code memory should be stored in a single memory chip (RAM/NVRAM)
(b} The external access pin should be tied to logic 0
(c) The external access pin should be tied to logic 1
(d) The PSEN\ and RD\ signals of8051 should.be ANDe_d to generate the output enable (OE\} of the memory
chip
(e} (a) (b} and (d} (f) (a) (c} and (d}
17. What is the number of general purpose registers supported.by the standard 8051 architecture
(a} 1 (b) 8 (c} 16 (d} 32
18. What is the number of bit variables supported by 8051 in the internal data memory area?
(a} 8 (b} 16 (c) 32 (d) 64
(e) 128
19. Bit address 07H contains logic 1, what is the value of bit 07H after executing the instruction MOV 20H, #0lH
(a} O (b) 1 .
20. Memory location 8 lH contains F0H. What will b.e the value of Accumulator after executing the instruction MOV
A, 81H
(a} 81H (b) OOH (c) FOH (d} Random data
21. The target controller is a standard 8051. Memory location 81H contains F0H. What•will be the value of accumula-
tor after executing the instructions
MOVR0, #81H
MOVA,@RO
(a} 81H (b) OOH (c) F0H (e) Random data
22. Name the register signalling the status of accumulator related operations
(a) A (b) B (c} PSW (d} SP
(e) None of these
23. How many user programmable general purpose bits are available in the status register of8051?
(a) 0 (b) 1 (c) 2 (d) 3
(e) 4
24. The accumulator content is 02H. What will be the status of the 'parity bit P' of the Status Register?
(a) l (b} 0
 Introduction to Embedded Systems

25. The accumulator contains 0FH. The overflow (OV) carry (C) flag and Auxiliary carry flag (AC) are in the set state.
What will be status of these flags after executing the instruction ADD A, #1
(a) OV = 0; C = 0; AC= 0 (b) OV = 0; C = 0; AC= 1
(c) OV=l;C=l;AC=l (d) OV=l;C=l;AC=0
26. The register bank selector bits RS0, RS 1 are Oand l. What is the physical address of register RO?
(a) OOH (b) 08H (c) 0FH (d) l0H
(e) 18H
27. The machine cycle for a standard 8051 controller consists of
(a) 2T States (b) 4T States (c) 6T States (d) 8T States
28. Which port of 8051 is 'true-bidirectional'?
(a) Port 0 (b) Port 1 (c) Port 2 (d) Port 3
29. For configuring a port pin as input port, the corresponding port pins bit latch should be at
(a) Logic 0 (b) Logic 1 4
30. Port 2 latch contains ASH. What will be tp.e value of Port 2 latch after executing the following instructions?
MOV DPTR, #0F00H
MOVA,#0FFH 4
MOVX @DPTR, A
w~ ~~ ~~ ~~
31. The alternate I/0 function for the pins of Port 3 will come into action only when the corresponding bit latch is 4·
(a) 1 (b) 0
32. The interrupts Timer 0 and serial interrupt are enabled individually in the interrupt enable register and high priority 4!
is given to Timer Ointerrupt by setting the Timer 0 priority selector in the interrupt priority register. It is observed
that the serial interrupt is not at all occurring. What could be the reasons for this?
(a) The global interrupt enable bit (EA) is not in the set state
(b) The Serial interrupt always occurs with Timer 0 interrupt
(c) There is no Serial data transmission or reception activity happening in the system 49
(d) Noneofthese (e) (a)or(b)or(c)
33. Timer 0 and External Ointerrupts are enabled in the system and are given a priority of 1: Incidentally, the Timer 0
interrupt and External 0 interrupt occurred simultaneously. Which interrupt will be serviced by the 8051 CPU?
(a) Timer O (b) External 0
(c) External 0 interrupt is serviced first and after completing it Timer 0 interrupt is serviced
(d) None of them are serviced 50.
34. What is the maximum ISR siie allocated for each interrupt in the standard 8051 Architecture
(a) l Byte (b) 4 Byte (c) 8 Byte (d) 16 Byte
35. What is the minimum interrupt acknowledgement latency in a single interrupt system for standard 8051 architec-
ture
(a) 1 Machine cycle (b) 2 Machine cycle (c) 3 Machine cycle (d) 8 Machine cycle
36. External 0 interrupt is asserted and latched at S5P2 of the first machine cycle of the instruction MULAB. What will
be the minimum interrupt acknowledgement l~tency time?
(a) 6 Machine cycles (b) 5 Machine cycles (c) 3 Machine cycles (d) 2 Machine cycles
37. What is the minimum duration in which the external interrupt line should be asserted to identify it as a valid
interrupt for level triggered configuration? 1.
(a) 1 Machine cycle (b) 3 T States (c) 2 Machine cycles (d) 3 Machine cycles
2.
38. What is the timer increment rate for timer operation for standard 8051 architecture
3.
(a) Oscillator Frequency/6 (b) Oscillator Frequency/12
(c) Same as Oscillator Frequency (d) Oscillator Frequency/24
4,
39. What is the maximum count rate for counting external events for standard 8051 architecture
5.
(a) Oscillator Frequency/6 (b) Oscillator Frequency/12
(c) Same as Oscillator Frequency (d) Osc:;illator Frequency/24 6.
40. Which is the 'Timer' used for baudrate generation.for serial communication?
(a) Timer 0 (b) Timer 1 7.
 Designing Embedded Systems with 8bit Microcontrollers-8051

41. The 'Timer' used for baudrate generation should run in

(a) Mode 0 (b) Mode 1 (c) Mode 2 (d) Mode 3
42. For 'Mode 0' operation, the 13 bit register is formed by
(a) 8 bits ofTH0/THl and least significant 5 bits ofTL0/TLl
(b) 8 bits ofTH0/THl and most significant 5 bits ofTL0/TLl
:;:.~
:,:,
(c) 8 bits ofTL0/TLl and least significant 5 bits ofTH0/THl
(d) 8 bits ofTL0/TLl and most significant 5 bits ofTH0l'J:Hl
43. The serial port of the standard 8051 architecture is
(a) Fullduplex (b) Halfduplex (c) 'Receive'buffered (d) (a)and(c)
(e) (b) and (c)
44. Name the 'Register' which acts as the 'Receive' and 'Transmit' buffer in serial communication operation?
(a) SCON (b) PCON (c) SBUF (d) Accumulator
45. Which of the following is (are) true about 'Mode 0' operation of serial communication· · '
(a) The baudrate is variable (b) The baudrate.is given as oscillator frequency/12
(c) The baudrate is same as os.cillator frequency (d) The baudrate is given as oscillator frequency/2
46. The' Auto Reload' count for 'Timer l' is FDH and the operating frequency is 11.0592 MHz and baudrate doubler
bit SMOD is 0. What is the baudrate for communication?
(a) 2400 (b) 4800 (c) 9600 (d) 19200
47. What will be the value of 'Program Counter (PC)' after a proper power on reset?
(a} FFFFH (b) 0O00H (c) Random value (d) 0001H
48. What will be the value of internal RAM after a reset?
(a) OOH (b) FFH
(c) The value before reset if the system is resetted during operation
(d) Random if the system is resetted immediately after Power ON
(e) (c) or (d) ·
49. Which of the following is (are) 'True' about 'IDLE' mode?
(a) The internal clock to the processor is temporarily suspended
(b) The various CPU status like SP, PC, PSW, Accumulator and all other register values are preserved
(c) All port pins will retain their logical state
(d) ALE and PSEN are pulled high
(e) All of these (f) (a), (b) and (c) only
50. A reset signal is applied to the 8051 processor when it is in the 'Idle' mode. How will the system behave?
(a) The idk mode setting bit IDL is cleared
(b) The processor resumes program execution from where it left off
(c) The processor resumes program execution from 0000H
(d) (a) and (b) orily (e) (a) and (c) only

Review Questions
1. Explain the various factors to be considered while selecting a microcontroller for an embedded system design.
2. Explain the architecture of the 8051 microcontroller with a block diagram.
3. Explain the different operating modes of 8051 (Hint: normal operation mode, power saving mode and ONCE
mode)
1- Explain the code memory organisation for 8051 for internal and external program memory access.
5.. ~~plain the data memory organisation for standard 8051 controller. ·
6,. pxplain the Von-Neumann memory model implementation for 8051 based system. What are the merits and demer-
1its of using a Von-Neumann memory model? . ·
7. Explain the memory organisation for lower 128 bytes of internal RAM for stand!itd 8051 architecture.
r
Introduction to Embedded Systems

8. Ex,plain how Port 0 acts as a normal VO port and multiplexed address data bus for external data/program memory
access?
9. What is the difference between Read Latch and Read Pin operation for port lines?
l 0. Why is Port 0 known as true-bidirectional?
11. Why is Port l known as quasi-bidirectional?
12. Ex,plain how Port 2 acts as a normal I/0 port and higher order address bus for external data/program memory
access?
13. Explain how Port 3 acts as a normal I/0 port and an alternate I/0 function port?
14: What is the difference between RET and RETI instructions for indicating the end of a subroutine call?
15. Explain how a third priority level can be achieved in 8051 interrupt system?
16. What is interrupt latency? What is the minimum and maximum interrupt latency time for a single interrupt system
in standard 8051 architecture? Explain in detail.
17. Explain the different conditions that block or delay the vectoring of an interrupt.
18. Explai!]- the different actions generated by the processor on identifying an interrupt request number.
19. The external interrupt INTO is enabled, and set to be level triggered. The Port pin P3 .2 is set at logic 0. Explain the
behaviour of the system.
20. Explain the operation of Timer 0 in Mode 0. Why is Mode Ooperation known as 8-bit Timer with a divide by 32
prescaler?
21. Explain the auto reload mode of operation of a timer. Give an example for the usage of Timer 1 in auto reload
mode.
22. Explain the Mode 1 operation of serial communication. How is configurable baudrate achieved for serial commu-
nication in Mode 1? What is the Timer 1 auto reload count for a baudrate of 9600 bits/second for a system working
at q.0592MHz?
23. What is multiprocessor communication? Explain the multiprocessor communication for 8051 for serial communi-
cation Mode 2.
24. How a 'power on reset' can be implemented for an 8051-based system? Explain the changes that happen to various
registers and internal RAM on a proper reset.
25. Explain the two power saving modes Idle and Power Down modes for 8051. What is the difference between the
two? Explain the methods of terminating each of the power saving modes.
26. Explain the Power consumption vis Operating Frequency characteristics for an 8051 based system. Why do the
characteristics curve contain an offset from the origin?
27. What are the different techniques that can be adopted for reducing the power consumption of an 8051 based sys-
tem?
28. What is On Circuit Emulation (ONCE) mode? How is ONCE mode enabled? What is the use ONCE mode in
system design?
29. Explain the difference between 8051 and 8052 microcontroller.
30. Only Timer 0 interrupt is enabled in the system and it is assigned a priority of l. It is observed that the timer inter-
rupt occurred only once and it is not occurring even though the timer roll over happens. The program does not
contain any instruction for disabling the global interrupt enable flag IE and Timer 0 interrupt. What could be the
reason?

Lab ~ssignments
1. Write an 8051 assembly l~11guage prg~a111 fq(~~fuittwI~ · 1J,ttf ;cl;,~ Jfuq11ghJh~ serial port with a ninth bit
which is used as an even patity bit: 1:hepr9ghµn sli~t1i4·§o'iµigute tf, . ;i(c,p~«ilication se~gs as: Ba~dr~te
= 9600, 1 start bit, 1 stop bit and also depending on theipar;tty'o~~t byte tb"b~sept; the parity bit sho~ld be
set properly.
 Designing Embedded Systems with 8bit Microcontrollers-8051

2. Write an 8051 assembly language program for receiving an even parity enabled 8-bit data through the serial potf
The program should configure the serial communication settings as:Baudrate =9600, 1 start bit, I stopbit:.l_Jff~~:
·. ~. > receiving the data byte, the parity ofitis cakulatea andit}i.verifieg .'Yith Jhfpartty bit received. Use int~i;i;qfifsf;
'?\\ for.implementing thes9rial data receptiort:' ·. . ·. ·
,?],;3-' ,J)~vdo,p ~. lJiV.9}Vare sy~t~rn"to'single st~P'te pro aln tritte.n for 80J1. 'I'he, ~rmwqre ni11p.ing in the C;Ilt
...• Se,i~tfi••r iste/,if!t 't;i.tt~W . .. ~j~4~i[t;;;;!J}. ~JJ:t .
,'I . , . ... ,~, ,r. . § , ••~J:~R;18~~~jf9~~6f,i~e;~~j,2~f';Iin~~~~tiiti
.. . stopbit,' o·par:1ty:· ~ . . .. . .
. :~. Develop an 8051 ,bas~d system fof dete9ti.ng th€,ke;ypress of a pus.n,bytto~ swi_tcl) connected to the
Pl,0 of the microcontroller: In,1pl~gient thf\yydfb<1%fii)g for thfp~sff:b\\tton in finnware (Upon'
· a keypress, the firmwar.evy~i\i✓r,()r 20 n1lliisecciri~~.artdJµlnchecks the l)Ush buttons.witch <lgai11,ift~
remains .inthedepressed state, the is a
ke)'pres.s iderititifd as valid key depression): For a validkeypressf
connected to port pin Pl .1 is activated for a pedoa of 1 second. Use aBC:547 transistor-based driver c·
.~~~ . ' . .

l,mpleme11Jthe 1tb.ove rtquircment using a hardware key de,-bounce circuit and connecting the push button
the external interrupt 0 pin of the controller: Implement the buzzer control logic in the Interrupt Sen{
tine for External Interrupt 0. .
·.. 6. Dev,elop an 8051-baseci.;~ystefn for 1etec~Jp,gj\~~.k,~ypr~1~§t~I}. ai;f~Y,;c1f~l~,~!19HflR~ syiflch~s.c'
'port pins p LO to p 1.7 of t4e microcontroUer.{lJ§iijf~n:~1iI\gat~ &eI1erate ap.ifte,fuatinMfrr'.42t si#
orie of the push button switch is depresseg,J~iritjJy 'iMRii·gu.§h,R~~g~Js, d~pfef~~<tl)Y ~~a.nni~f ,.,
the push button connected port pins, in the' interi11p(§~ry1?tfpufinf lodft~;~t~i\aJ.}#t~qµpt.'fhf;p~·
SC!\nned in the qrder Pl .0 to PL7. }3ven lf m •... :.. )P~§Bfittons ,a,r.~.,d§pr~S,1!g;J!}~f\rsfiq~~,,Aftl
switch is recognlsea as the valict keypress'.. Usea"l.iafoware;key de·-lJounce c1rcuit/ft 'for implementmg
de-bouncing for all push buttons. An 8 ohm spe~~er is connected to·port. ·. 2:0. G~ner~te.~i
:··varyin'g;the frequericy(say ·l MHz, 20GHz, 300Hz?§OO:Ui, etc) of the. p}i.se . ·• fut.<rd af~hep JJiJl i.
tt
the speaker is com1ected, corresponding to each push button: press. Use 13C547 trinsisfor based 'ct<lvir~f
s
driving the speaker: · ·• . ·· · · . ·. · •. ··: · ·>
e 7. Design an 8051 based system fqr interfacing an. Rf traµ§ceiv~r (e.g:CRF'ModeHf/iom SUNROM Te
gies http://www.sunrom.com/index;php?main_page=proif.u,ct_injd.&cPath-lilJ9&jJrodiicts_:_Jd=56()) an·.
e > >driver circµit using an NPN transistor for driving anormally open relay with· ?otrvo)tage 12V'for 's <'
' · Alternating Current with ratings 5Ainps and 50Hz. Connect a 100W/240V bulb through the relay. Tum ON:a@•
· OFF the bulb in response to the command received by the RF transceiver. The commands are sent by an..applic:a.'~
tion running on PC through an RF transceiver.
8. Implement the above system using infrared (IR) remote control and receiver, supporting the RCS protocol (e.g .
.n
TV remote and SFH 506-36 IR receiver unit (Use the reference design http://\:\'WW.atmel.com/dyrvresources/
pr.ad <locuments/docl 47..1J)df from Atmel for SFH 506 interfacing)), in place of the RF based control implemen-
tation.
r- 9. Develop a miniature 'Traffic Light Control' system based on 8051 and LEDs for controlling the 'Red' 'Green'
ot and 'Yellow' signal lights present at a junction where four roads meet The 'Green' and 'Red' signal will be qn
1e for a duration of 30 seconds and 'Yellow' for 5 seconds.
IO. Develop a simple electronic calculator using 8051 microcontroller with 16 push button keys arranged in a 4x4
matrix for representing digits Oto 9, operators+,-, X, %, and 'Clear' button. Use tvvo 7-segment LEDs for
displaying the result. Only single digit operations are allowed. The system requirements are listed below.
(a) Upon power on both the 7-Segment LEDs display 0
(b) \\Then a numeric key is pressed, it is <lisp layed on the rightmost 7-segment LED
(c) Enter the first operand (digit) by pressing the corresponding push button
(d) To perform an operation(+,-, x, %) press the corresponding push button
(e) Now press the second operand (digit)
(f) Press the '=' operator for displaying the result of the operation
/
(g) Pressing the 'Clear' key at any point clears the display and displays 'O' on both LED displays. For division
1
operation, display the quotient as result.
 L~arH:the fondjtignqtplqg{a'r!i contr~(trarJsfer inJtruetio'!f(Pec:t¢ment,and Jump if non ,zero,-.Compare ·and jump if
no{equ~i, juri?p if i:a;ry'f(ag fsset or notset, Jump i{a speciffed bit .is~' 'set dtnof _etc.) ~upportei:1
' ., -, ' , .
by :8051

As you learned in the basic 8085/8088 microprocessor class, an Instruction consists of two parts name-
ly; Opcode and Operand (s). The .opcode tells the processor what to do on executing an instruction.
The operand(s) is the parameter(s) required by opcode to complete the action. The term instruction Set
refers to the set of instructions supported by a processor/controller architecture. The instruction set of
805 I family microcontroller. is broadly classified into five categories na111ely; Data transfer instruc-
tions, Arithmetic instructions, Logical instructions, Boolean instructions arid program control transfer
instructions. Before going to the details of each type of instructions, it is essential to understand the
different addressing modes supported by the 805 I microcontroller.
 Programming the 8051 Microcontroller

The tenn 'addressing mode' refers to ·"How the operand is specified in an instruction" along with
opcode. The operand may be one or a combination of the following-memory location(s), contents of
memory location(s), register(s),.or constant. Depending on the type of operands, the addressing modes
are classified as follows.

6.1. l Direct Addressing

The operana is specified as an 8 hit mem.ory address. For 8051 processor, only the lower 128 byte
internal data memory and the SFRs are directly accessible.
For example, MOVA, 07H (Moves the content of memory location 07H to the accumulator. 07H
refers to the address of data memory at location 7. If memory location 07H contains the value 255,
executing this instruction will modify the content of A to 255) uses MOV as opcode and A, 07H as
operands (Fig. 6.1).

Registers Data memory

t Memory
A
address
B
RO
I 07H 255 (FFH)
I ····--

I R7
I

6.1.2 Indirect Addressing .

As the name indicates, the operand is specified indirectly in indirect addressing. A register is used for
holding the address of the memory variable on which the operatioI?-S are to be perfonned. The indirect
operations are performed using @register technique. For 8-bit internal data memory operations, register
RO or Rl •is used as the indirect addressing register. The whole 256 bytes (if present physically on the
chip) can be accessed by indirect addressing.
MOV RO, #55H Load RO with 55H, The address of mem loc
MOV A,@RO Load Accumulator with the contents of the-
,. memory location pointed by RO
Register RO is loaded with 55H (85 in decimal) on executing the first instruction. Here RO is used as
the indirect addressing register and data memory 55H is the memory variable on which the operations
are performed. Executing the second instruction moves the contents of memory address 55H to the ac-
cumulator. This can be interpreted as MOVA, content @Memory Address 55H. Suppose 55H contains
255, executing the second instruction will load the accumulator with 255 (Fig. 6.2).
 Introduction to Embedded Systems

Data memory

A
Memory
address
:,:; B
~:~1 RO 55H
55H 255 (FFH)

R7
I
Among the scratchpad registers RO to R7, only RO and Rl can be used for indirect addressing. For
16bit external data memory/memory mapped register operations, 16bit register DPTR is used as the
indirect addressing register. The whole 64K bytes of the external memory (if present physically on chip)
can be accessed by indirect addressing.

Executing these two instructions moves the content of external data memory at address OO55H to the
Accumulator (Fig. 6.3).

Registers External data memory

♦
A Memory
address
B
DPH OOH ~

DPL 55H --,,. OO55H 255 (FFH)

§~@ Illustration oflndirect memory addre~sing with 16bit Indirect Register (E.g. MOVX.A, @DPTR)

Indirect addressing is same as the pointer concept in C Programming. Indirect addressing is com-
monly used for operations similar to pointer based operations in C Programming like array, external
memory access, etc.

6.1.3 Register Addressing

Register addressing is of two types. In some instructions, the register operand is implicitly specified by
some bits of the opcode. These types of instructions are referred as Register Instructions. Some instruc-
tions implicitly work on certain specific registers. T,hey are known as Register Specific Instructions.
 Programming the 805 I Microcontroller

6.1. 3.1 Register Instructions In register instructions, the register operand is specified by some
bits of the opcode itself. If scratchpad registers RO to R7 are used as operands, they can be specified
along with the opcode by using the last 3 bits of the opcode. Such instructions are code efficient since
the opcode itself specifies one operand; it eliminates the need for storing the operand as a byte in code
memory and also saves the time in fetching the operand. Generally register variable access is faster than
general memory access.
'Mov RO,. 01w

This is a two byte instruction where the first operand RO is indicated by the last 3 bits of the opcode
byte.
Register to register data transfer is not allowed and hence instructions like MOV RI, R2 are invalid.
6.1.3.2 Register Specific Instructions Some of the 8051 instructions are specific to certain regis-
•ters. Examples are accumulator and data pointer specific instructions.
A, #s:o
During the assembly process, this instruction is converted to a two byte instruction in which A is
implicitly specified by the opcode corresponding to ADD.

6.1.4 Immediate Constants

Constants can be an operand for some instructions. If an instruction makes use of a constant data as the
operand, the type of addressing is called immediate addre~sing. In immediate addressing, a constant
follows the opcode as operand in code memory. An immediate constant is represented with a leading
'#' symbol in the assembly code. A leading '#' tells the assembler that the operand is a constant. For
example, if you want to load accumulator with the constant 9, the following instruction will do it.
MOV A, .j/:09 '

6.1.5 Indexed Addressing

Indexed addressing is used for program memory access. This addressing mode is used for reading look
up table from code memory and is Read Only. A 16bit register is used for holding the base address of the
lookup table. The offset of the table entry from which the data to be retrieved is loaded in Accumulator.
The instruction MOVC is used for indexed addressing.
E.g. MOV DPTR, #2008H
MOVA, #00
MOVC A, @A+DPTR
The above example assumes that the lookup table is at memory location 2008H and so the base ad-
dress of the lookup table is 2008H. The first instruction loads the base pointer address 2008H to the
base pointer register DPTR. The table index is provided by the accumulator register. To access the cor-
responding entry of the table, load accumulator with the offset from the base address. For accessing the
base element the offset should be 0. The second instruction loads the offset to accumulator. For example,
if you want to access the entry which is just above the base entry, the accumulator should be loaded with
1. Executing the third instruction moves the content of the table entry at memory location 0+2008H-t~
the accumulator. Since the offset address register, accumulator, is an 8bit register, the maximum size of
the look up table is 256 bytes (Base address + 0 to Base address + 255).
 Introduction to Embedded Systems

Another register, which is 16bit wide, used for indexed addressing is Program Counter (PC). The
only difference in using PC for indexed addressing when compared to DPTR is that the PC is not avail-
able to user for direct manipulation and user cannot directly load the desired base address to the PC
· register by a MOV instruction as in the case ofDPTR. Instead the desired address is loaded to the PC by
diverting the program flow to the location where the Lookup table is held in the code memory by using
a CALL instruction.
F_irst the desired table index is loaded to the accumulator register and a call is made to the location
where the lookup table is stored. For this type of tables, the index should be within 1 to 255 (including
both). 0 cannot be used as an index since the execution of MOVC A,@A +DPTR increments the PC to the
of
address the RET instruction's memory location. If you use a Oindex along with the PC, the contents
retrieved will be the binary data corresponding to the RET instruction. Code memory lookup tables are
usually u~ed for storing string constants and other configuration data. Another use of indexed addressing
is the ' case jump' instruction in 8051. Here the jump instruction's destination address is calculated as the
1

sum of the base pointer (PG) and the Accumulator data.

Write an assembly program to display the numbers from Oto 9 on a ?-segment common-anode LED display which is
connected to P~Hi 2 of the 8051. The seven segment codes for displaying the numerals Oto 9 on the common anode LED
is stored as lookup table in the code memory starting at 0050H. Use DPTR register for holding the base address of the
table.
Please refer to the section on ?-segment LED Display given in Chapter 2 for more details on ?-segment LED Display.
Figu~e 6.4 illustrates the interfacing of common anode LED Display with Port 2 of 8051.

---------.-Vee

Common anode
?-segment LED display

DP G F E D C B A

(Fig. 6.4) Circuit for interfacing 7-segm.ent LED 'display with 8051
 I.

Programming the 80S 1 Microcontroller

Now we need to design the different bit patterns (code) to be outputted to the Port 2 pins to displa>1the numbers from
Oto 9 on the LED Display. The following table explains the same. Refer to the LED segment arrangembnt diagram given
earlier for clarification.

Now the codes for

displaying the digits and the port interfacing for the LED display is complete.'
The next s'tep required for setting up the decimal counter for counting from Oto 9 is the development of
firmware.,The flow chart given in Fig. 6.5 illustrates the firmware requirements for building the decimal
counter.
Start

Store the display codes corresponding to Oto 9 in

code memory location starting from 0050H ·

I. Initialise Port 2
2. Initialise Stack Pointer
3. De-select ADC chip
4. Load DPTR with the base address oflook-up
table stored in code memory

Initialise Index Register to 0

I. Get the 'Display Code' from the code memory

address pointed by DPTR and Index Register
YES 2. Load P2 with the data retrieved from code
memory
NO
I.Wait for 1 second
2. Increment Index Register
 Introduction to Embedded Systems

The firmware for implementing the decimal counter is given below.

;###############################################################11###
;7_Segment_LED_DPTR.src
;Firmwaie•for: Implementing Decimal Counter and displaying count in
;?.Segment LED Display
;The
s -~ :., ,
displ
'
9 y code
. ' '
for
' •.,
displaying
'. '
digits
~
.
O to 9 ,ate stored in code-
;memory starting from code mem9ry .. address 0050.H,
Pr~e PPTR 'register 'holds the .bise address ·. o.f' the lookup, table-
dieilding the ~di'splioi·y .'.cOctes .· ,Ach~fflljl'ator: •iS'US~d a,s' the '.i:ndei.:C:.• '
; regi;s't,:er<fo:r rett!fe~'.ing the, coctet corresponding ,·to' Q
· ;frprn CO(fodrnemory. Written,'& Compi:led f.Dr A51 Assembler
;W,t) tten by Bhibu K v. Copyright· (C) 2dos
>
; ###.# ## ### U ## # ### #### ### # ## ###### # # # ## ## #####U# # U #f### ### #At# U.t# #f .
•">\,t, .:, _.;.; :.
ORG·· 0023H
ORG ·oooott Reset vector
JMP 0100H ., Jump to code mem location 01.POH to
,. execution
·oRG 0003H Exteiria1 Interr~pt O '1SR. locati~n
RETI Simply return. Do n'othing . ·_ .
ORG OOOBH Timer O Interrupt ISR location
RETI Simply return. Do.'nothing
ORG 0013H External Interrupt 1 ISR location
RETI Simply return. Do nothing
ORG OOlBH Timer 1 Interrµp·CrsR }ocation
RETI Simply return. Do nothing
Serial Interrupt ISR location
RETI Simply return. Do nothing
;####################################################################
;Define the codes for displaying the digits from Oto 9
;The codes are stored in a lookup table in code memory-
;starting from 0050h
;The DB definition usage is assembler specific
ORG 0050H
DECIMAL_CODES: DB OCOH, OF9H, 0A4H, OBOH, 99H, 12H, 02H, OFSH, 80H,90H
;####################################################################
; Start of main Program
ORG 0100H
MOV P2, #OFFH Turn off all LED segments
MOV SP, #08H Set stack at memory location 08H
MOV DPTR,#0050H Load the lookup table start address
RESET: CLR A Set index to zero.
MOV R7,A Backup index register
 Programming the BOS I Microcontroller

REPEAT: MOVC A,@A+DPTR ; Get the display code

MOV P2, A ; · Lo~d P2 with Display code
CALL DELAY .Wait for: 1 second
1NC R7 ; Incrementc·'index-
MOVA, R7
CJNE A, #10, .Rli}EAT. \ ;_ Are ·c3;:J.1 -~ aigits "displa:yed?
.. i All 9 digiis cti':§pla.yetf. ~Re:;et; c3u~'te'i t'o. 0
,'/';'-·i:: > . J~P ~ESE!_ . ';/;_ . . . "'
,'~\ J#_t~i_ff.UUtHtfl!llt ' l( *:~f:i#ff##UUUH#J#i
,,:.,,,,,,_

\::6ncts)
delay · ·
. j~o~icro~~-;c@is

'.S:X998030rrticrosecohd§} qel,;3,y . . . .
"_{fuh'~}rout:in~ -~en:.erate$' -a'p~e~i:se deJiy .Q'.f, -0d99/s~ciilnds . -· ·,. <: . -: , .·-.
:~,Jiitf t.f tlit ti ft f Jf #fl i Hi# t't.t f ##'iii#.#°#'# funio#i#i#J ##n ##J J#i# H
/bti:A:n . MOV 'R21-, no -
:· rl.,
,. \::,'i;; , ,. ,)}., , ::/.-,:~- :.
,-_LOOPl: ·MOV,Rl, #200···

tt&st}: .~~~zRkb, #:~6~3

0 ~~\.
DJNZ R1TffiOP2 .
. ' ../ DJNZ R2, LOO.Pl
RET
END ;END of As 9 embly Program

6.2 THE 8051 INSTRUCTION SET

As mentioned earlier, the 8051 Instruction Set is broadly classified into five categories namely; Data
transfer instructions, Arithmetic instructions, Logical instructions, Boolean instructions and Program
control transfer instructions. The following sections describe each of them in detail.

6.2.1 Data Transfer Instructions

Data transfer instructions transfer data between a source and destination. The source can be an internal
data memory, a register, external data memory, code memory or immediate data. Destination may be an
internal data memory, external data memory or a register.
6.2.1. 1 Internal Data Transfer Operations Internal data transfer instructions perform the move-
ment of data between, register, memory location, accumulator and stack. MOY instruction is used for
data transfer between register, memory location and accumulator. PUSH and POP instructions transfer
data between memory location/register and stack. The following table summarises the various internal
data transfer instructions.
 Introduction to Embedded Systems

:t(''
MOV<dest>,
<src> ·

'pointed

. XC:fID A,@Ri
;_. (i~O or 1) · 1A1i:t;t/)i~·;t·
MOV 111struction copies the content of source to destination. Only the destination is modified. The
sourct:> data remams unchanged.
6.2 l 2 Stack Memory Related Data Transfer ·Stack' 1s an internal memory for storing variables
ternrnr:in h 'Stack memory 1s nom1ally used for storing the data during subroutine calls. In 8051, by de-
faul1 Llil· :--wck memory 1s allocated from the memory location 07H onwards by loading the stack pointer
(SP) register \\ ith 07H on power on reset. PUSH instruction stores data on stack memory. The PUSH
instrucuon Jirq mcrements the SP by one and copies the data to the memory location pointed by the SP
register ,,u P mstruct1on retrieves the data, which is stored on the stack memory using PUSH instruc-
tion. POP mstruct1on copies the data stored in memory location pointed by SP register to the variable
t Fo1 ,ill data transCcr msm1ct10,1 mvolvrng an immediate constant as the source. and scrntchpad rt'g1ster RO to R7 as the destination
(e g '\!( J\ R,1 c:110. \10\ 'ii Rf\ LO(), rhc execut10n cycle :s l machine cycle.
 Programming the 8051 Microcontroller t· .·
'■"'•"'""
. .

given along with POP instruction and decrements the SP by one. In 8051 architecture the stack memory
grows upward in memory and follows Last In First Out (LIFO) method. PUSH and POP instructions
use only direct addressing mode and hence the instructions PUSH RO, PUSH Rl, PUSH A, etc. are not
valid. They are valid only if the arguments are usefr with absolute addressing. Hence the valid instruc-
tions corresponding to them are PUSH ARO, PUSH ARl, and PUSH ACC, etc. The operation of PUSH
and POP instructions are illustrated in Fig. 6.6 and Fig. 6.7.

Registers Data memory

Memory
SP 07H address
RO

Llcood RJl _ _
with 55
Get Contents of RO_..
MOV RO • #55
PUSH ARO I Increment SP register * 07H
Store the Contents of
RO at Memory Location
~

~
55 08H
* Random Data Pointed by SP

Registers Data memory

Memory
SP 08H
* Random data address
RO

Retrieve the contents * 07H

Load RO with the POP ARO +- oft_he memory loc~tion _
POPedData Pomted by SP register 55 08H
Decrement SP register

The upper 128 bytes of RAM are not implemented physically in the basic 8051 architecture and its
ROMless counterpart 8031. With these devices, if the SP is set to a location in the upper 128 byte area,
the PUSHed bytes will be lost and POPed bytes will be indeterminate.
6.2.1.3 Data Exchange Instructions The data exchange instructions exchange data between
a memory location and the accumulator register. Data exchange instructions modify both memory
1e location and accumulator register. 8051 supports two data exchange instructions, namely, XCH A,
<memloc> and XCHD A, @Ri.
The XCH A, <memloc>. instruction performs the exchange of the data at memory location 'memloc'
with the accumulator. By using MOV instructions the XCH instruction can be implemented as
e-
er
H
;p
.c-
1le It requires three instruction~ and 4·machine cycles and a temporary variable RO to achieve this.
ion Whereas theXCH A, <memloc> accomplishes this faskwith a single instructioniap.d one machine cycle.
 Introduction to Embedded Systems

The XCHD A,@Ri (where i = 0 or 1) instruction exchanges the low nibbles between the accumulator
and the data memory pointed by the indirect memory register RO or Rl. Both XCH and XCHD are
accumulator specific instructions. The operation of XCH A, <memloc> and XCHD A,@Ri instructions
are illustrated in Figs 6.8 and 6.9.

A
Registers

OFH
Memory
address

07H
Data memory

FOH
I
Before executing XCH A, O7H instruction

Registers Data memory

Memory
address
A FOH
07H OFH

After executing XCH A, O7H instruction

~-----------------------__J

Registers Data memory

Memory
address
A OFH
07H FOH
RO 07H
Before executing XCHD A, @RO instruction

Registers Memory Data memory

address
A OOH
·01H FFH
RO 07H

After executingXCHD A, @RO instruction

i
(_!'i-Jiii} Illustration of XCHD A,@Ri Instructic>,n

6.2.1.4 External Data Memory Instructions External data memory instructions are used for
transferring data between external memory and processor. The registers involved in external data mem-
ory instructions are the Data Pointer (DPTR) or the indirect addressing register RO/Rl and the accumu-
lator. Only indirect addressing works on external data memory operations. If the external data memory
is 16bit wide, a 16bit register DPTR is used for holding the 16 bit address to function as the external
memory pointer. During 16bit.extem:al data memory operations Port Oemits the content ofDPL register
(Lower order 8bit address) and Port 2 emits the content of DPH register (Higher order 8 bit address).
 Programming the 8051 Microcontroller

If the external data memory is only 8bit wide, either the DPTR or the indirect address register RO
or Rl can be used for holding the 8bit address to function as the external memory pointer. If DPTR is
used as the memory pointer register, Port Oemits the content ofDPL register (Lower order 8bit address)
and Port 2 emits the content ofDPH register. If RO or Rl is used as the memory pointer register, Port 0
emits the contents of RO or Rl register (Lower order 8bit address) and Port 2 emits the contents of its
SFR register (P2 SFR). The instruction mnemonic used for external data transfer operation is MOVX_
and depending on the memory pointer register the operand will be RO, Rl or DPTR. The accumulator
is the implicit operand in MOVX instruction. The direction of external data memory operation (Read
or write operation) is determined by the use of the accumulator register. If the accumulator register is
used as the source register, the external data memory operation is a Write operation and the WR\ signal
is also asserted. The external data memory operation is a Read operation if the accumulator is used as
destination register. This also generates the RD\ signal.
External data memory related instructions are listed in the table given below.

The following sample code illustrates how to read and write from and to an 8bit external memory.
Method-1
Using Indirect register RO

MOV RO, #OSSH Let SSH be the external data memory

address
MOVX A,@RO
MOVA, #OOH Clear Accumulator
.
Reads the content of 55H to accumulator

MOVX @RO, A Writes Oto external memory SSH

Method-2
Using Data Pointer (DPTR) Register
MOV DPTR, #SSH Let SSH be the external data memory
address
MOVX A,@DPTR Reads the content of SSH to accumulator
MOVA, #OOH Clear Accumulator
MOVX @DPTR, A Writes Oto external memory SSH
The following sample code illustrates how to read and write data from and to a 16bit external
memory.
 Introduction to Embedded Systems

Below is given the Instruction fetch and execute sequence for the MOVX instruction.

T State

Clock Cycles

11 11
ALE~ l
,--~
~---~-: L --
I

: ---+----------~:If-,! :
PSENJ I ~-~ ~-~ I
I I I
I I ·I
RD ---------.;e--~ ~---+-1------+---
1 I
I I
I I
I I

P2 ~=x~:_P_C_H_o_u_t~ DPH or P2 SFR out=><: l PCH out Nf_H_o1

IinN
.. T ~
@><CL
out , INST
m
~ - --- ----

( Fig. 'e:10) .Ti~ing ~iagr,1IDtf<ii'~9VX ,~sti~~t~o·n.wb.en th~fJri>~~~em~~yis ~~~t,1tiil

"
MOVXis a two machine cycle instruction. The opcode fetching starts at state-I (Sl) of the first ma-
chine cycle and it is latched to the instruction register. A second program memory fetch occurs at State 4
(S4) of the same machine cycle. Program memory fetches are skipped during the second machine cycle.
This is the only time program memory fetches are skipped. The instruction-fetch and execute sequence
and timing remains the same regardless the physical location of program memory (it can be either inter-
nal or external). If the program memory is external, the Program Strobe Enable (PSEN) is asserted low
on each program m_emory fetch and it is activated twice per machine cycle (Fig. 6.10). Since there is
no program fetch associated with the second machine cycle of MOVX instruction, PSEN is not asserted
during this (two PSEN signals are skipped). During the second machine cycle of MOVXinstruction, the
address and data bus are used for data memory access.
The lower order address bus is multiplexed with the data bus in 8051 and Port Ooutputs the lower
order addr¢ss Bu~ during external memory operations and ~- is ~vailable at S5-S6 states of the first
 Programming the 80S1 Microcontroller

machine cycle. Since it is available only for a short duration of I to 1.5 states, it should be latched. The
trigger for latch is provided by the signal Address Latch Enable (ALE). ALE is asserted twice in each
machine cycle (during SI Phase 2 (S1P2) and S4 Phase 2 (S4P2)). Since data is outputted to or read
from the external memory at State 1 (SI) to State 3 (S3) of the second machine cycle, during a MOVX
instruction, ALE is not emitted at S1P2 of the second machine cycle. Without a MOVX instruction ALE
is emitted twice per each machine cycle and it can be used as a clock signal to any device.
The control signal PSEN is not asserted if the program memory is internal to the chip. However,ALE
signal is asserted even if t~e prograrl1: memory is internal.
The external data memory timing for external data memory write is similar to the Read operation
except that the control signal used is WR\ instead of RD\ and the data for writing is available in the place
of' Data in' in the above timing diagram . The timing for all signals remains the same.
6.2.1. 5 Code Memory Read Instructions Code. memory read instruction is used for reading
from the code memory. There is only one instruction for code memory read operation and it is MOVC.
Detailed description of MOVC instruction is given in an earlier section with subtitle "Indexed Address-
ing''. Please refer back.

6.2.2 Arithmetic Instructions

Arithmetic instructions perform basic arithmetic operations including addition, subtraction, multipli-
cation, division, increment and decrement. The various arithmetic instructions supported by 8051 are
listed below.

,''\' ',', :J;-5}f(, s;/(,y··~~;

it U:Q
1)'"> 'l[ .. •.· :•can:be
·. register's ItO,R , .)R'h~fa11f SFifhr .
an int~at . . Iiffmory of~rr'.iihtii~4i4te .
constatit>or ,an::interii~l 1;oata" ni~fii/Jcy ·
pointed indirectly:by, ii;fdifect apd.resifug
register RO or RI ifild@
 Introduction to Embedded Systems

•.·. Incremeitts tl!e .copfent :oF~loc::> by 1.

OM\be,registersl3;;:tw;R1, ... R.7,
.•. .·<lpc>
<· ,. :, '·.·:: ,.,,,, ...,-,_,· '' ·;'. -i . ,,_ .,jl·--.,, ". '. ,,, ' •· :-. ,.'1><'."
··.,.,.~- . . . :
orany.S:Fll:.9~.aq;£&!f ... tneruory .
. fotema.l :gtata ID,eµio'i ,pqint~d ·
,!it:~f~;t~f~i;Ijf,:~:SI!:,:~:~~: 1

;,~

·"'b~tilµ~fi~iHJu!
BC . ,~thfuetjc ;

6.2.2.1 Addition and Subtraction The 8051 supports the addition of 8bit binary numbers and
stores the sum in the accumulator register. The instructions ADD A, <lac> and ADDC A, <lac> are used
for performing addition operations. Both of these instructions are accumulator specific, meaning the
accumulator is an implicit operand in these instructions. The ADD A, <lac> is used for perfo1ming a nor-
mal addition and the can-y flag gets modified accordingly on executing this instruction. [f the addition
results in an output greater than FFH, the carry flag is set and the accumulator content will be the final
result-FFH + carry. The carry frag is reset when the result of an addition is less than or equal to FFH.
The ADDC A. <lac> instruction operates in the same way as that of ADD A, <loc> instruction except
that it adds the cany flag with A and <foe>. The changes to the carry flag on executing this instruc-
tion remains the same as that of executing the ADD A, <loc> instruction. Executing these instructions
modify the content of accumulator only and <foe> remains unchanged.
The instruction SUBB A. <foe> performs the subtraction operation. The can-y flag acts as the borrow
indicator in the subtraction operation. The SUBB A, <lac> instruction subtracts the borrow flag and the
contents pointed by <loc> from accumulator and modifies the accumulator \Vith the result. The content
of <lac> remains unchanged. For performing a normal subtraction operation, first clear the carry flag
 Programming the 80S 1 Microcontroller

and then call the SUBB A, <loc> instruction. The carry (borrow) flag gets modified accordingly on ex-
ecuting this instruction. If the subtraction results in a -ve number (' A' less than (<loc-:> + Carry)), the
borrow (carry) flag is set and the accumulator content will be the 2's complement* representation of the
result (e.g. Accumulator contains OFER and borrow (carry) flag is 0, executing the instruction SUBB A,
#OFFH results in -1 which is represented in the accumulator by the 2's complement form of 1. Hence
the content of accumulator becomes FFH (2 's complement form of 1) and the borrow (carry) flag is also
set). The carry flag is reset when the r~sult of a subtraction is +ve (' J.; is greater than (</oc> + Carry)).
The SUBB A, <loc> instruction is accumulator specific, meaning accumulator is an implicit operand for
this instruction.

The accumulator register contains 80H and B register contains 8FH. Add accumulator content with B register. Explain
the output of the summation and the status of the carry flag after the addition operation.
Adding 80H with 8FH results in 1OFH. Since 1OFH requires more than 8 bits to represent, the accumulator holds only
the least significant 8 bits of the result (Here OFH). The carry bit CY present in the Program Status Word (PSW) register
is set to indicate that the output of the addition operation resulted in a number greater than FFH. Figure 6.11 illustrates
the addition operation and the involvement of Carry bit (CY).

D7 D6 D5 D4 D3 D2 D1 DO

I 1 I O I O I O I O I O I O I O I 80H

ADDA,B +
8FH

OFH

(fig; 6, 1l) lilustration cof ADD instruction operation

Register RO contains OBH. Add the contents of register RO with the suin obtained in the previous example using ADDC
instruction. Explain the output of the summation and the status of the carry flag after the addition operation.

I The instruction ADDC A, RO adds accumulator content with contents of register RO 1J,nd the carry flag (CY). Before
executing this instruction, the accumulator contains the sum of previous addition operation, which is OFH and the carry
flag (CY) is in the set state. Register RO contains OBH. Executing the instruction ADDC A, RO adds OFH with OBH and
1. The resulting output is lBH which is less than FFH. This resets the carry flag. Accumulator register holds the sum. It
should be noted that each addition operation sets or resets the carry flag based on the result of addition, regardless of the
previous condition of the carry flag. Figure 6.12 explains the ADDC operation.

* 2's complement of a number= l's complement ofthenumber+l·

I
I

!
Introduction to Embedded Systems

D7 D6 D5 D4 D3 D2 Dl DO

0 I OIOIOIOI I 1 I 1 I 1 I OFH

ADDCA,RO + \SY(
~ I 0·I O I 0 0
1
I 1 IOl I 1 l
1 1 1
OBH

vvvv

The accumulator register contains 8FH and B register contains OFH. The borrow Flag (CY) is in the set state. Subtract
the contents of accumulator with borrow and B register. Explain what is the output of the subtraction and the status ofthe
borrow flag after the subtraction operation.
8051 supports only SUBB instruction for subtraction. The SUBB instruction subtracts the borrow flag (CY) .and the
number to be subtracted, from accumulator. Th~ subtraction operation is implemented by adding accumulator with the
2's complement of borrow flag and the 2's complement of the numberto be subtracted.
The 2's complement of borrow flag (CY=l) results in FFH:The 2's complement of B register content (OFH) yields
Fl ff The accumulator content is added with the 2's complement of borrow flag (8FH + FFH) and the result (8E) is added
with..the 2's complement of B register (8EH + FlH). This results in 7FH with the borrow flag (CY) in the set state. The
final step in the subtraction operation is complementing the borrow flag (Carry Flag). A value of 1 for borrow flag after
complementing indicates that the result is negative whereas a value of Oindicates that the result of subtraction is positive.
If the result is negative, accumulator contains the 2's complement of the negative number. Figure 6.13 illustrates subtract
with borrow operation and the involvement of borrow bit (CY).

6.2.2.2 Multiplication and Division The instruction MUL AB multiplies two 8birunsigned num-
bers and stores the 16bit result in the register pair A, B. The accumulator stores the lower order ·8 bits of
the result and B register stores the higher order 8 bits of the result. The overflow flag (OV) is set wh~n
the product is greater than OFFH and cleared otherwise. The carry flag becomes cleared state irrespec-
tive of the product. '
The DIV AB instruchon divides the content of accumulator register with the content ofB register and
stores the integerpart of the quotient (A/B) in accumulator and the modulus (A¾B) in B register (e.g. If
A contains 03H and B contains 02H, executing the instruction DIVAB loads accumulator with OlH (3/2)
and B register with OlH (3%2). 8051 does not have a divide by zero interrupt mechanism to indicate a
divide by zero error. However.8051 indicates the divide by zero condition by setting the overflow flag
· {OV) in the Program Status Word (PSW) register. The values returned in A and Bare undefined for a
' divide:by-zero operation. - ·
The overflow flag (OV) and carry flag (CY) are cleared for normal division operation.
MUL and DIV instr:uctions are accumulator and register B specinc instructions. They work only with
these t\\'.O registers. If register B is not used for multiplication and divisiun, it can be used for temporary
storage.
 Programming the 8051 Microcontroller

IOI O I O I OI OI O I O 11 I OIH

l's Complement of
Carry 11 I I I 1 I 1 I 1 I 1 I 1 I O I FEH

2's Complement of
Carry l's I 1 1 1 1 1 1 l FFH
Complement of I I I I I I I I
Carry+ l

O 0 O O l I I OFH
l I I I I I I I I

l's ComplementofB 1 l l O O O O FOH

I I I I I I I I I

2's Complement of B
= l's Complement of 1 1 l 1 O O 0 I FlH
I I I I I I I I
B+l
I O O O 1 l ·sFH
I I I I I I Il I I
+
SUBBB
CY
I
1
I
1
I
I I-I 1
Il I
1
I
1
I
FFH
l 1 1 1 I 1 1 I
vvvvvvvv
0 I1 l 0
l 0
l 0
1i-1 1
I
1
I
O
I
8EH

l l 1 1 O O O FlH
l
I I I I I I I I I
V

0 I
0
I
1
I
1
I
1
I
1 I ·1 I
I I
7FH

Convert the binary number FFH present in the accumulator to unpacked BCD and store the resultant 3 digit BCD number
in consecutive memory locations starting from 20H
1

Introduction to Embedded Systems

BCD numbers are numbers with base l 0. BCD numbers use digits Oto 9 for representing a number. They are nonnally
used for representing a meaningful decimal number. Each digit in the BCD number represents the consecutive powers
of 10. For example, the BCD number 255 is interpreted as 2 x 10 2 + 5 x 10 1 + 5 x 10°. Binary numbers follow the base
2 numbering system. Regardless of the numbering system, digital systems internally represent the numbers in binary
format. For an 8bit word length controller/processor, the maximum number value that can be represented in binary is
11111111, which is equivalent to FFH in hexadecimal and 25 5 in decimal. For retrieving the digits of a decimal number,
the number is divided with 10 repeatedly until the quotient is zero. The remainder from each division gives the succes-
sive LSB digits of the corresponding BCD number. For example, for 255, the first division gives the quotient as 25 and
remainder as 5, hence the LSB digit for the BCD number is 5. The next division of the quotient by 10 gives 2 as quotient
and 5 as remainder. The remainder 5 forms the next LSB digit for the BCD. Performing one more division with 10 on
the quotient (2) gives Oas quotient and 2 as remainder. This remainder acts as the MSB digit for the corresponding BCD
number. In fact for an 8bit binary number, only two divisions are required. The remainders from the two consecutive divi-
sions form the consecutive LSB digits for the BCD number and the quotient after the second division becomes the MSB
digit for the corresponding BCD number. The following assembly code implements this principle. The DIVAB instruction
performs the successive divisions with 10.
;#########f###############################################f###I######
;binary uiipacked bc&.src
; Firmwa-;::e for co-;:;-verting binary number
' ~ '. ; j .;, • : !
unpacked'Eico·
' ·,. ' ',. •
·
t<:fi.•';,,;'-:_",-,-~,'.-_ :<
·•.;,,

· ; The binary number. to be ·conve-rted is present in the accum11l~tO,):.\ .

The BCD° Correspond.fog ,to the corivert~d •binary is ~to~~a. in-. ,. ''
;memory loc~ti~n}rst¥rting froiµ 20H with 'the least significant digit
; of BCD stored in' mernoty locatiori · 20H .
;Written & Cornpitecl. for l\,51 Assembler
;Written by Shibu' K,V. Copyright {C) ioos ' .• ,. '·
; ## ### # # # # # # ## ## i # # #H ## #U #### H####Uf### ######HO####### #fr#######
ORG OOOOH Reset vector·
JMP 0100H Jump to start·of main program
ORG 0003H Extei,nal Interrupt O ~SR locat.ion
~ETI Simply return. Do nothing
ORG OOOBH Timer O Interrupt ISR location
RETI Simply return. Do nothing
ORG 0013H External Interrupt 1 ISR location
RETI Simply return. Do nothing
ORG OOlBH Timer 1 Interrupt ISR location
RETI Simply return. Do nothing
ORG 0023H Serfal Interrupt ISR location
RETI Simply return. Do nothing
;####################################################################
; Start of main Program
ORG 0100H
MOVA, #OFFH Load Accumulator with the binary number
MOV RO, #20H Load the mem location for storing BCD Digit
MOV Rl, #2 Load division counter
CONTINUE:MOV B, #10
DIV AB
MOV @RO,B B holds the remainder, which is the BCD
INC RO Increment mem loc to store next BCD Digit
DJNZ Rl,CONTINUE
MOV @RO,A The last BCD digit is the quotient
JMP $ Loop forever
,.END ;END of Assembly Program
 Programming the 80S1 Microcontroller

@~~niJ>le 2 )
Convert the packed BCD number '98' stored in the accumulator to corresponding binary number and store the result in
accumulator.
The packed BCD number is stored using a single byte, The higher 4 bits of the byte store the most significant digit of
the packed BCD number. and the lower 4 bits store the least significant digit of the BCD number. Hence the accumulator
representation of packed BCD is 1000 IO00b (98H). The binary value corresponding to this packed BCD is the binary
representation of 9 x 10 1 ~ 8 x 10° ~ x 10 + 8 x 1 = 90 + 8.
###'#U####.Ul#l#ll<###iUl########H#######O##itH##U#######Hit###H##
lciedbcd t6:J~iila;ryrsrc . .. . . · .. · .,
i!i~~E1re~;,~9r1~ehv'.~riJng :pack12d BCD to hi'nary
i.,J?C?num:r:l~:r-f·to:·12e c9rrverted'.is ,present in, accumulator
0

~ ;;esultan't pii)ary. :1umber is held in~Accumulator register

itt:pn & ass,~mb:J;e,q tor: _A51 As~emble;r .
itten by Shibu ..'K V•. Copyright (0) 2008
##################################################################
Reset vector
'.'JMP 0100H ., Jump · to st~rt of main program
03H ; External Jnterruph () ISR loca'tion ,
Simply. -ret\1:cn. Do 'nothing
Timer O Interrupt ISR location
RETI ; simpiy ~et~rn. D~
IlothJng
13H. External Interrupt/)' fsR ldcat,ion
., Simply retu'rn_. -Do nothing
·; TimE;r 1 :i:'iiterrupt ISR loqatipn
RETI Simply return. Do· nothing .
0023H ; Serial Interrupt ISR locati6n
.RETI Simply return. Do <nothing
;.U##H################U#####U,###l#U####U##############J###Jt#U # 0

· ; Start of main Program

ORG 01008
MOV _A, #98H Packed BCD representing 98
MOV RO, A Backup BCD number
SWAP A ; Extract the MSB of packed BCD
ANL A, #OFH Extract the MSB of packed BCD
MOV B, #10
MOL AB Get the positional weight for MSB digit
MOV Rl, A Store the temporary result
MOV A, RO Retrieve the original BCD number
ANL A, #OFH Extract the LSB of packed BCD
ADD A,Rl Final result
JMP $ Loop forever
END ;END of Assembly Program

6.2.2.3 Increment and Decrement The increment instruction (INC) increments the content of
the location pointed by the operand. The INC A instruction is an accumulator specific instruction which
increments the content of accumulator. Executing the instruction LtvC A will not modify the carry flag.
The INC <foe> instruction increments the content pointed by <loc>. If the content pointed by the
 Introduction to Embedded Systems

operand of /NC.jnstruction is FFH, on executing the INC instruction, the content simply rolls over to
OOH. None of1he status bits are modified to indicate this rollover. INC DPTR instruction is DPTR regis-
ter specific instruction and it increments the content of 16bit DPTR register by one. The following piece
of assembly code illustrates the usage of INC instruction.

The decrement instruction (DEC) decrements the content of the location pointed by the operand. The
DEC A instruction is an accumulator specific instruction which decrements the content of accumulator.
Executing the instruction DEC A will not modify the carry flag. The DEC <loc> instruction decrements
·the content pointed by <loc>. If the content pointed by the operand of DEC instruction is OOH, execut-
ing the DEC instruction simply rolls over it to FFH. None of the status bits are modified to indicate this.
The following code snippet illustrates the usage of DEC instruction.

There is no specific instruction to decrement the DPTR register content by one in 8051 instruction
set. However decrementmg the DPTR can be achieved by using other instructions in the optimal way.
6:2.2. 4 Decimal Adjust The DA A instruction adjusts the accumulator content to give a meaningful
BCD result in BCD arithmetic. Binary Coded Decimal (BCD) is a number representation in numeric
systems. In the BCD number system, numerals ·from Oto 9 are used for representing a number. Based
on the number of BCD digits represented in a single byte, the BCD numbers are known as packed and
unpacked BCDs. In the unpacked BCD representation, a single BCD digit (0 to 9) is represented by a
single byte whereas in the packed BCD representation two BCD digits (00 to 99) are represented using
a single byte. ADD and ADDCinstructions used for BCD addition should follow a DA A instruction to
bring the Accumulator content to a meaningful BCD result. It should be noted that the DA A instruction
will not convert a binary number to a BCD. The DA A instruction always follow the ADD instruction.

Write an assembly program to add two_packed BCD numbers '28' and '12' stored in consecutive memory locations start-
ing from data memory address 50H. The result of the addition should be adjusted for BCD.
The Assembly code snippet shown below illustrates the implementation.
 Programming the 8051 Microcontroller

tMt:*f#!*.###UW##t~*f*'
it.1Xin:,;'.stc ' · · · ..
!t'f
,?·":;,
V-V•

fEi'

,Dec,:{;~'l: ~~} . ' ,s,e ~Js~{t

1

,Loop forev§'r.
; END of Assembly P-rogra:m

If the accumulator is not adjusted for decimal, after the addition, the accumulator content will be
3AH. Adjusting the accumulator for decimal, after the addition operation, produces a meaningful result,

l 40H (Which is the sum of the BCDs 28 and 12).

6.2.3 Logical Instructions

Logical instructions perform logical operations such as 'ORing', 'ANDing', 'XORing', complement-
ing, clearing, bit rotation and swapping nibbles of a byte, etc. The list of logical instructions supported
by 8051 is tabulated below.
 Introduction to Embedded Systems

t c'tl~struction Actiol} Comments • ·Machine · ;'.'

f~ 'i::lJ\lf\~A!!JlliC -£,;i}1:9YJ,!;:;1 ;;,
ORLA,<loc> A=Al<loc> Perform bitwise logical OR the content 1
of Accumulator with the content of <loc> ·
and stores the result in Accumulator. <loc>
can be registers B, RO, R1, ... R7, or ariy ··
SFR, an -immediate constant, an internal
- :,; data memqry or an foternal ~ata rn,ez;npi%
' .· •· •· pointed in<lirectly -by: indirect !iddiessing';>
{};:.register ~Q;9rR(?,~d@ . -••.:tr I;;·;_,,

Bitwise logical AND

accumulator with the content of<loc> and
stores ·the result in memory location <loc>.
<loc> can be any SFR or an internal data
memory
ANL <loc> ,#const <loc> = Bitwise logicaLA,ND the content qf ~109.>, ; ,· .·'·•
l::1oc>&const - with an immediate constant and st&f~s ttiif:;C,
· resultinmemory location <loc>. <·loc>c;R' ·.•· ·
be any SFR or an internal data memory· )~
XRLA,<loc> A A/\<loc> Bitwise logical XOR the content of the
accumulator with the content of <loc> and
stores the result in Accumulator. <loc> can
be B, RO, RI, ... R7, or any SFR, an internal
data memory or an immediate constant or
an internal data memory pointed indirectly
by indirect addressing register RO or Rl
and@
 Programming the BOS 1 Microcontroller

The ANL instruction perfonns bitwise ANDing operation. The operation of ANL instruction is il-
lustrated below. Suppose the Accumulator contains 80H and if it is· ANDed with an immediate constant
80H, the following actions shown in Fig. 6.14 take place.
Accumulator I O IOI OIOIOl O: 0 ! 80H

AND operation & & & & & & & &

Constant \ 1 j O\ 0 \ 0 ! 0 \ 0 \ 0 \ 0 80H

Result in
accumulator I I O I O I O O I O I O I O I 80H
i

~g,6.1~ Illustration of ANL instruction operation

 Introduction to Embedded Systems

Similarly the ORL instruction performs the bitwise ORing operation. For example, let us assume that
the accumulator contains OlH and it is ORed with an immediate data 80H. The result will be 81H and it
is stored in the accumulator. It is explained in Fig. 6.15.

Accumulator
IO I
O 0
I
[ oI oI oI o i 1 I 0lH

'OR' operation

Constant
I1 I
O O O O O O O
I l I l I I I 80H

Result in O O O O O O 1
accumulator I1 I I I I I I I I 81H

TheXRL instruction performs the bitwiseXORing operation. The principle of XOR is that if both the
XORing bits are same (both are either Oor 1) the·output bit is Oand if theXORing bits are complement
to each other the output bit is 1. For example, if the accumulator content is 8lH and an XOR operation
of the accumulator with an immediate constant 80H yields OlH as output. The.xRL instruction operation
is explained in Fig. 6.16.

Accumulator
I1 I o I o I o.J o Io Io 11 i 81H
A
'XOR' operation A A A A A A A

O O O O O O O
Constant
I1 i l I I I I I I
80H

Result in
accumulator IO I
O O 0
I I
I 0
I
O 0
I i l i OlH

The CLR A and CPL A instructions are accumulator specific instructions. The CLR A instruction
clears the content of accumulator (loads accumulator with OOH), whereas the CPLA instruction comple-
ments the accumulator content (negates the accumulator content). Both CLR A and CPL A instructions
are single machine cycle instructions.
Assuming accumulator contains FOH, Fig. 6.17 illustrates the operation of CLR A and CPL A
instructions.
Rotate instructions rotates the bits of the Accumulator. All Rotate instructions are Accumulator spe-
cific instructions and Accumulator is the implicit register for rotate operations. Accumulator bits can be
either rotated to left or right.
The RL A instruction rotates the accumulator bits to the left by one position and the MSB of the ac-
cumulator comes in place of the LSB. For example, the accumulator contains 80H, after executing an
RL A instruction, the contents of the accumulator will become OlH. It is illustrated in Fig; 6.18.
The RLC A instruction is similar in operation to RLA instruction except that in RLC A instruction the
MSB of the Accumulator is shifted to the Carry bit (CY) and the content of carry flag at the moment
 Programming the 8051 Microcontroller

Accumulator I 1 I1I1I 1 I OI OI O I OI FOH

A~cumula!or after C~R A I O I O I O I O I O I O I O I O I OOH

mstruct1on execut10n . . . . . . . . .
(a) CLR A instruction operation

Accumulator FOH

'CPL' operation

OFH
(b) CF:LA instruction operation

~'!Mi~~~t1~~~~f(~).'.~i~,t~sr\(ije~!~~;~,~~~aii;~!_:c~#.~wl~,i~t~~\jp~~!hi#11

Accumulator ~ 1~~80H

Result in Accumulator
after RLA instruction 0 I O I O I O I O I O I O ·1 1 I OIH
1
execution

of execution of the RLC A instruction is shifted to the LSB of Accumulator. The operation of RLC A
instruction is illustrated in Fig. 6.19. Assuming the Accumulator contains 80H and the carry bit is in
the cleared state (0). Executing the RLC A instruction sets the carry flag and modifies the Accumulator
coritent to OOH.
CY

Accumulator

CY

Result in_ Accumulator

after RLC A instruction oI oI oI o oI oI oI o1 OOH
execution

One more execution of the RLC A instruction .will change the accumulator content to OlH and resets
the carry flag.
 Introduction to Embedded Systems

The RR A instruction rotates the accumulator bits to the right by one position and the LSB of the
accumulator comes in place of the MSB. For example ifthe accumulator contains OlH, after executing
the RR A instruction, the contents of the accumulator will become 80H (Fig. 6.20).

Accumulator~
~l~OIH

Result in Accumulator
after RR A instruction I 1 I O I O I O I- 0 I O I O I O I 80H
execution

The RRC A instruction is similar to RLC A instruction ·except that in RRC A instruction the LSB of
the accumulator is shifted to the carry bit (CY) and the content of carry flag at the moment of execution
of RRC A instruction is shifted to the MSB of the accumulator. Assuming that the accumulator contains
0 lH and the carry bit is in the set state (1 ). Executing the RRC A instruction sets the carry flag and
modifies the accumulator content to 80H (Fig. 6.21 ).

CY

Accumulator

Carry Flag after RRC A CY

instruction execution
Result in Accumulator
~
after RRCA . I O I O I OI O I O I O I OI 80H
1

instruction execution
( Fig. 6~21) Illustration of RRCA i~struction operation

The SWAP A instruction interchanges the lower and higher order nibbles of the Accumulator. Assum-
ing the accumulator contains F5H, executing SWAP A instruction modifies the accuinulafor content to
5FH.
The SWAP A instruction is very helpful in BCD to binary conversion.

6.2.4 Boolean Instructions

The 8051 CPU provides extensive support for bit manipulation instructions. Internal RAM of 8051
contains 128 bit-addressable memory and all SFRs whose address ends with OH and 8H are bit address-
able. Boolean instructions are used for performing various operations like bit transfer, bit manipulation,
logical operations Of!. bits, program control transfer based on bit state, etc ..·
 Programming the 8051 Microcontroller

Accumulator FSH

Result in Accumulator [ 0 1 0 1
after SWAP A instruction _ _ _ _ _
I I I I I_ I_ I_ I_ 5FH
execution
Higher Nibble Lower Nibble
[:f'fg, 6.'22) Illustiation:':of SWAP A in~truetion ope~ation

The cany bit 'C', present in the Special Function Register PSW, takes the role of accumulator in all
bit related operations. The various Boolean instructions supported by the 8051 CPU are listed below. It
is to be noted that all bit access is through direct addressing only.

Logical OR·Carry flag with Bit and store the re~~lt .. ·-- - ,
QRLC, Bit C =CI Bit 2
in Carry flag ·
.the co ' . r-~" ,,
.
]fa ~JRi;ri.ltin~';
,_.,g_, "•'·~•"'· .,. ,_., ...,.,
-- . .

- CPL C C=JjOT.C Corµpiements the Carry flag···

}j;. ,•{: ·,.c,j'.J .... ·:_. , :,:.•·";'" •;»:••;'"<\:.";;""""'"'__ . _"•""''"~-~~-•";" _--'_ .··:•

t"/Pr:L~1_k · J:IO=z:i'l'<:rn:i~it''!tGo!iiple~entsJ3it
t The actual state of the bit remains unchanged. If bit OH is in the cleared state, executing the instruction ANL C, /OH will not change
the state of bit OH to set.
tt The actual state of the Bit remains unchanged. If bit OH is in the cleared state, executing the instruction ORL C, /OH will not change
the state of bit OH to set.
 Introduction to Embedded Systems

The Boolean instructions are very useful in bit manipulation operation for bit-addressable SFRs.
Manipulation of port status registers (PO to P3) is a typical example. The usage of Boolean instructions
is illustrated below.
MOV ;C>, P2. 0 , Load carry Hag with Pprt ..pin 2; 0' s status.
MOV P2,0,,c;: Load Port 2. O latql}, of: carry,.:flag
SETB C. Set the · flag
CLR ·c Clear carry flag. .
ANL C, P2.0 Logical AND P2.0 Latch bitswith .Carry flag and
load Carry bit with the result
The JC rel and JNC rel instructions has got special significance in comparison operation. The 8051
supports only one compare instruction, CJNE, which checks only for the equality of the register/data
pair compared. There is no built in instruction for checking above or below condition (Compare and
jump if above and Compare and jump if below). These conditions can be checked by using the JC and
JNC instructions in combination with the CJNE instruction. The CJNE instruction followed by the JNC
instruction implements the Compare and jump if above condition and the CJNE instruction followed by
the JC instruction implements the Compare and jump if belov1.J condition. The following code snippet
illustrates the same. Assume that the accumulator content is 50H and it is compared against 5 lH.
//Implementation of Compare and Jump if above
CJNE .A, #51H,above?
; Check whether accumulator content is greater than 51H
; The Carry flag is cleared if Accumulator>= const
above?: JNC acc_high
Accumulator< 51H. Do the rest of processing here
acc_high:; Accumulator>= 51H. Do the rest of processing here 't
f
//Implementation of Compare and Jump if below
CJNE A, #51H, below? tl
Check whether accumulator content is less than 51H A
; The Carry ~lag is set if Accumulator < const
p:
tc
 Programming the 8051 Microcontroller

6.Z.5 Program Control Transfer Instructions

The Program control transfer insti;uctions change the program execution flow. The 8951 instruction set
supports two types of program cpntrol transfer instructions namely; Unconditional program control
instructions and Conditional program control instructions. They are explained below.
: !

6.Z.S.l Unconditiqnal Program Control Transfer Instructions The unconditional program

control instructions t~ansfer the progq1m flow to any desired location in the code memory. The uncondi-
tional program control instructions sripported by 8051 are lishid below. ·

Jump Instructions The instruction JMP represents three type of jumps. They are SJMP, LJMP and
AJMP and they are used in appropriate contexts. If the programmer is not interested in analysing the
contexts, he/she can simply use the JMP instruction.
S/MP instruction stands for Short Jump. The destination address is given as an offset to the current
address held by the Program Counter (PC). The SJMP instruction is a two byte instruction consisting of
the opcode for SJMP and the relative offset address which is one byte. The jump distance fc;,r the SJMP
instruction is limited to the range of-128 to+ 127 bytes relative to the instruction following the jump.
LJMP instruction stands for Long Jump. The destination address for LJMP is given as the real physi-
cal address of the code memory location to which the jump is intended. The LJMP instruction is a three
byte instruction consisting of the opcode for LJMP and the two byte physical address of the location to
which the program flow is to be diverted. The jump location can be anywhere within the 64K progra111
memory.
The third type of jump instruction AJMP stands for Absolute Jump. The AJMP instruction encodes
the_ de~tination ad_dres~ as 11-b~t constant. T~e instruction is tw? byte long ~ons_isting of th~:'Qpcod~::
which itself contams higher ~. bits of the 11-bit c9nstant. Rest 8 bits of the destmation address is held by!
the second byte of the instructjon. When an Al~ instruction fs executed, these 11 bits are substituted
for the lower 11 bits in the 'Program Counter (PC). The higher S1bits of the Program Counter remains
the same. Hence the destina,tion will be within the same 2K block of the current instruction. In general
AJMP is used for jumping within a memozy block.
The programmer need not bother about handling these three jumps, what he/she can do is simply
provide the destination address as label or a 16 bit constant. The assembler converts the JMP instruction
to any of the three jump instruction depending. on the context.
 Introduction to Embedded Systems

Case jumps for diverting program execution flow dynamically can be implemented using JMP
@A +DPTR instruction. The destination address is computed during run time as the sum of the DPTR
register content and accumulator. Normally DPTR is loaded with the address of a jump table which
holds jump instructions to the me1I1ory location corresponding to a 'case'. For an n-way branching
requirement, the accumulator is loaded with Othrough n-1. The following code snippet illustrates the
implementation of a switch case statement using JMP@A +DPTR.

Corresponding switch case implementation in 8051 Assembly using JMP@A+DPTR

· ,
;i~~:¥I
, :DPil'R
.L; t tliftif.fi'fft:liU ~ ,
:cl\sl TiitE = ,: .': :-•''::, , -· ,

AJ11R.C,l).,SE..O.,; :IWJ!f:,'}:8:\ · ,li,?f1::'i~p,};~~~niitg,.~~~ti;, .. ,.. Jjg\~\. . ~•: :.-.:~ ~

AA;:JMJM;··,·.~pp: .,:.'.tc_:AA."ss.·,'"EE.' "_2t., :~ll!J1P:,,tg,},: _, ,J=.i~n., ~~pJe1t:rtt?_~·~.¢.o.if?§~:tP?:S,~l:;'. './'. ·, ,:;. ·;_
. . , •Jump to lo:c\ition i_mp:Le:m~i:i,tip,9,c;od.e'.~qr,,S::.A$E2 · ,, '
CASEO.: ,, Ac:t:fon'.cOi:re;:,pona:frl:i. {?'EJ1~:o ;;.c .• :.'''•;. '/'.:'',._"· ;/.',.,
CASEl: ''•'; 'f-, i Action ·co~~;sp~"haT;g t~ ca;el . > • '

CASE2: Action corresponding to case2 ··

Locations CASEO, CASEl and CASEZ. should contain the action item to be implemented for each
case statement.
The subroutine calling instruction CALL is of two types; namely LCALL and ACALL. LCALL is a
three byte instruction of which the first byte represents the opcode and the second and third bytes hold
the physical address of the program memory where th-0 subroutine, which is to be executed, is located.
For LCALL the subroutine can be anywhere within the 64K byte of program memo1y. ACALL is similar
to AJMP. ACALL is a two byte instruction of which the first byte holds the opcode as well as the higher
3 bits of the 11-bit address of the location where the subroutine is located. The second byte holds the
remaining 8 bits of the address location. ACALL is used for calling a subroutine which is within the 2K
block of the instruction, calling the subroutine.
RET in~truction performs return from a subroutine call. Executing the ·RET instruction brings the
program flow back to the instruction following the CALL to the subroutine. RETI performs the return
from an interrupt routine. RETI instruction is similar to the RET instruction in all respect except that the
RETI informs the interrupt system that the interrupt iri progress is serviced.
 Programming the 8051 Microcontroller

The NOP instruction does not perform anything specific. It simply forces the CPU to wait for one
machine cycle. It is very useful for generating short waits. It simply eats up the processor time. For
example, if you need a short delay between the toggling of a control line/device select line or port pin,
simply add some NOP instructions. The following code snippet illustrates the usage of NOP instruction
in programmmg.
SETB P2. Q Pull P2~0 line HIGH
NO!:> ~ Hold P2.0 line HIGH for 2 machine cycles
(ijQf
CLR P2.0 ; ~eleas~ P2.0 line

6.2.5.2 Conditi<;mal Program Control Transfer Instructions The conditional program control
transfer instructions transfer the program flow depending on certain conditions. The program flow is
diverted from the norrn~l line only if a specified condition is met. The conditional program control trans~
fer instructions supported by 8051 are listed below.

h
Compai~;the content of <loc> with
an i~ediate :Constant and jumps to
a
d
. 'CJNE <loc>, If (<l,oc>!= #data) are
the relative address 'rel' if both
2
· #data, rel Jump to 'rel' not equal. <lo<i>·can be a memory
!. pointed indirectly or register RO
lT through R7 or.Accumulator.

te , All the conditional branching instructions specify the destination address by relative offset method
K and so the jump locations are limited to~ 128 to+ 127 bytes from the instruction following the condi-
tional jump instmction. Even if the user specifies the actual address, the assembler converts it to an
offset at the time of assembling the code.
Unlike the 8085 and 8086 CPU architecture, there is no zero flag for 8051. The instructions JZ and
JNZ instructions implement the zero flag check functionality by checking the accumulator content for
zero. DJNZ instmction is used for setting up loop control and generating delays. CJNE instruction com-
pares two variables and check whether they are equal. CJNE instruction in combination with the carry
 Introduction to Embedded Systems

flag can be used for testing the conditions 'greater than', 'greater than or equal' and 'less than'. The two
bytes in the operand field of CJNE are taken as unsigned integers. If the first is less than the second,
the Carry bit is set ( l ). If the first is greater than or equal to the second, the carry bit is cleared. Boolean
~nstructions are also used for conditional program control transfer. Please refer to the "Program Control
Transfer based on bit status" under the Boolean Instructions section for more details.
Please refer to the Online Learning Centre for the Complete 8051 Instruction Set reference

Summary )
✓ An Instruction consists of.two parts namely; Opcode ;md Operlmd(s). The.Opcode tells the propessqrl'Y~~}tb dg{i
on ex1;cuti~g an instruction: Qperand(s) is the parameter(s) requi.red by opcode tocompletethe;fqtrpµf;j0~l:r\} 5:j
✓ Addressing,Mode refers to the way in which an operand is spe~ified in an,instruqtion alongwitliAh,
•· ✓ Direct Ad~essing, .Indirect Addressing, Register Addressing, Immediate Addressing and Indexedl'
.;.,csthe a9dressing:1n9flis sµp~or.t~.d by 8051 · . . . . -'~ . .. . · . ·
./ . Instrµ9tion~ in which the :register operand is implicitly srecified by some bits of the qpcode refi
lnstructi~ns, wher~_as in.structions which implicitly work 611 cei-t~in specific.registers are kn ·
Spe~ific'ln~trµctions ·.. . . . . ··. . ' ·: , .,. • ·• ·::; . . . .·· ,," >: • •
1 7

Tlie iu~t1'.ilqtion:~er9f 80Jl f~ijtily mi~ rogAI1trol\ec1ibro~9ly ilassiµed jnt9 TI?\! c~tiiories, A~ ·
, , instrudit>n~, Arithmetic mstructidris,Ligrcar:{µ'stniµtions, Boof¢in m~tnictio~s]~a ·Prograh{
. "-·,·:instru;'t'ions ' ...... ··' . ' ••,.
L, • ."?.'•, . . ' .:L',"'"'.: .,·ot"
J,. ",'·" " . ·, ,:, • _,, ,;;,.'

✓ 'Stack' is an internal memory for stoi;ingVadablci~ltelllpOrtHlf The'instniction PUSH saves da~to .

the instruct:ioilPOP retrieves the pushed ci~ta fi;oinJhe 'stack'tnemory . ·· . . ·. · . '<
✓ ,Data\ransfetinstructions transfet_data bet:w~e,n a source and destination. ffhe:data transfer"°:~:
register or memory (internal or external). Arithm:ytic j,nstructions,petfom,i arithmetical operati91:l;S
subtraction, multiplication, division,,incremen(and .decrement · , .· ··•· •
✓ Logical instructions perform logicatopetation,ssuch as 'ORitig', 'ANDing' >xORing',· coniplein
ing,bit rbtationand swapping ~ibbles ofa byte, etc .. . . <:.(,.
¥ Booleaninstructions perform various operatirin~ like bit transf~r, hit manipulation/logical operaffo# _.
program control transfer based on bit state, etc. The carry bit 'C', present in the Special Function Register
takes the role of Accumulator in all bit rylated operations · ·· ..
✓ P:rogram Control transfer instructions change the program execution flow. The 8051 instruction setsuppori:s two
tjrpes of program control transfer instructions na111ely; Unconditional program control instructions and Condi-
tipnal program control instructions
✓ Tpe unconditional program control instructions transfer the program flow to any desired location ip. the code
111emory. JMP,.CALL, RET, RETI and NOP are the unconditional program control transfer instructions in 8051
iristruction set ,
I
✓ T~e conditional program control transfer instructions transfer the program flow depending on certain yO)-lditions.
Tlie program flow is diverted from the nonnal.line only if a specified condition is met. Jump on Zero (JZ), Jump
ori Non Zero (JNZ), Decrement and Jump if Non· Zero (DJNZ), Compare and Jump if not equal (CJ,'l~ffi), Jump
i(specified bit is set (JB), Jump if specified bit is not set (JNB), Jump if the, bit is set and clear the bit (JBC),
Jump if Carry flag is set (JC) and Jump if Carry flag is not set (JNC) are the cohd~tional program cpntrol tian~fer
instructions in 8051 · . . , ,
✓ The DJNZ instruction is used for setting up loop control and generating delays. CJN_E instruction compares two
variables and check whether they_are equal. CJNE instruction in combinatio~ with the Carry flag can be used for
testing the conditions 'greater than', 'greater than or equal' and 'lessithan' 1.
 Programming the 8051 Microcontroller

~ Keywords r•;~·- J,
Opcode : The COffiWai1~-t~~l~ell{ltlt>?#t6iiiiBtW~M't'
Op~rand(s) : The pararuete~(s) required by,'1ll tlpcode 1o ?·
Ad4r~s~i1;1g MQde : Theway,in whJg~faA±9P~1-~~~,i~jt?'~,~~~{r
pire,tt Addr~ssing .: The addressii;ig ·II!94.· . .. .. ' u ' ' ;.,r
j~direct i<l dressing : The addressin ,:mode ·
rectly)1s· ,5.;;,
,Sil~~st~t{\gdf~,~~i~g ,0, F :_-Addtesf
_;~egisterlrrstr:Ucnons'<j . : Imitry~ti
;;, -, · . ·. · , , , :,j.?. . ·opc~de .
!?,4l,egister:Specific'Iqstrµctions :. 1llistt\ifk'. ,
; ifumedill!e ~ddt~ssfog• · . . : Acldr~ssingffi ,
·:.iit&~ie.dAodressiiifl:,t · . . •·r AUdi~ssirtg;,iid
tiiJta Transfer Instni~tio'ns : Instrucfio ,' ,'',
t:s£a:ck . •. ,, . . . " : Intehliilili
PUSH
~ , ,.
: ---·Inst~gtiillfof
~--.; ;;':y;.'.. ;.\,<t --_-,:}.s\>:1,";Y::
. 'pop ·. . .. . . .·. . . . . .. . · : Instrucfiq1'.'f~f
,$ail Exchang~lnstrll'ctiohs : Insthl~ti~#~~:fo .
•. ·. · · . . register _in ~QJ.l ar~.
i~){~xtern,aJ:Data Meitiory : Instructtifofor'tF::'
{cilitih1ctlon ,, , •. .' ~ ·{t':f .,
'A.~ithm~tic.Instructions : In~ti\i~tiqR~it'
..• tioq; !Ilulttpl1~·. ,, .
. ~2's .Comple()lent . : A bi~~IY;1~t~J~f~~
.J,linaryCoded Dec;imal(BfD): Nunibers\vit~'~rufo . / . . ,, J
Unpacked BCD : Asingle.BCD digif (Ofo,9):
/?Jlifcked'BCD . . ,.., ·: Two BCD clf~its'YPOtq'99.\r
.· :f!~c(mal Adjust Accumulafor : An irrsltuctib,11'fQfaclj .
(I)AA) after BCD arithmetic · ..
Logical Instructions : Instructions for perfonniiig lo~ka.l &pef~9M .j{{ . i ,;,f,A:N:OiµJf ,. 'KOR-
ing'' complementing, clearing, btl fo~tio~. < . .ol~f
(Ri>{ii . ·.·.' . • of Jtiyte, etc

I Boolean Instructions Instructions for performing various '&peratfons :iike )oitldriisfet~ ,?it map'ipulation,
logical operations on bits, program control transfer based oh.bit'stat~, itc .

Objective Questions
What are the different addressmg modes supported by 8051?
(a) Direct Addressing (b) Indirect Addressing (c) R~gister Addressing (d) Indexed ~ssing
(e) Immediate Addressing All of these
2. Which is the addressing mode for the instruction MOY A, #50H
(a) Direct (b) Indirect (c) Immediate (d) None of these
3. Which is the addressing mode for the instruction MOY A, 50H
(a) Direct (b) Indirect (c) Immediate (d) None of these
4 Which is the addressing mode for the instruction MOY A, @RO
(a) Direct (b) Indirect (c) Immediate (d) None of these
 Introduction ·to Embedded Systems

5. Which is the addressing mode for the instruction MOVC A, @A+DPTR

(a) Direct (b) Indirect (c) Immediate (d) None of these
6. Code memory starting from 0050H holds a lookup table of 10 bytes. The first element of the lookup table is OOH.
What is the content of accumulator after executing the following piece of code?
MOVA, #OOH
LCALLTABLE
NOP
ORG004EH
TABLE: MOVCA, @A+PC
RET
(a) OOH (b) 22 (c) 22H (d) Undefined
(e) None of these
7. Register RO contains 50H and Accumul~.tol' contains OlH. What will be the contents of RO and A after executing
the instruction MOV A,RO
(a)'RO OlH;A=OlH (b) R0=50H;A OlH (c) RO=OlH;A=SOH (d) R0=50H;A=50H
(e) None of these
8. Data memory location· OOH contains FOR and Stack Pointer (SP) contains 07H. What will be the contents of
memory location OOH and SP after executing the instruction PUSH OOH
(a) Data memory location OOH 07H; SP = 07H (b) Data memory .location OOH = FOR; SP = 07H
(c) Data memory location OOH= FOR; SP= 08H (d) Data memory location OOH= FOR; SP= 06H
(e) None of these
9. Data memory location OOH contains FOR and Stack Pointer (SP) contains 08H. The memory location 08H contains
OFH. What will be the contents of memory location OOH, 08H a.nd SP after executing the instruction POP OOH
(a) Memory location OOH OFH; Memory location 08H ;.= FOR; SP= 08H
(b) Memory location OOH = FOR; Memory location 08H FOR; SP = 07H
(c) Memory location OOH= 0FH; Memory location 08H = OFH; SP= 07H
(d) Memory location OOH = 0FH; Memory location 08H = OFH; SP = 09H
(e) None of these
10. Data memory location OFH contains OOH and the accumulator contains FFH. What will be the contents of data
memory location 0FH and the accumulator after executing the instruction XCH A, OFH
(a) Memory location 0FH = OOH; Accumulator= FFH
(b) Memory location OFH OOH; Accumulator OOH
(c) Memory location 0FH = FfH; Accumulator = OOH
(d) Memory location OFH = FFH; Accumulator= FFH
(e) None of these
11. Data memory location OFH contains ASH, Accumulator contains SAR and register RO contains OFH. What will be
the contents of data memory location OFH, Register RO and. accumulator after executing the instruction X<::.HD A,
@RO
(a) Memory location 0FH = ASH; Accumulator= 5AH; RO 0FH
(b) Memory location 0FH 55H; Accumulator=:= AAH; RO 0FH
(c) Memory location 0FH =AAH; Accumulator 55H; RO= 0FH
(d) Memory location OFH = ASH; Accumulator= 55H; RO= AAH
(e) None of these , . I
i
12. Register DPTR holds 2050H. Explain the result of executing the instruction MO VX@DPTR, A
(a) P2 SFR 20H; Pl SFR 50H during the first machine cycle; RD\ signal is asserted once
(b) P2 SFR = 50H; P 1 SFR 20H during the first machine. cycle;, RD\ signal is asserted once
(c) P2 SFR = 20H; Pl SFR = 50H during the first machine cycle;'WR\ signal is asserted once
(d) P2 SFR =50H; Pi SFR = 20H during the first machine cycle; WR\ signal is asserted once
(e) None of these ·

I
 Programming the 8051 Microcontroller

13. The Program Strobe Enable (PSEN) signal is asserted during program fetching if
(a) The progra::ri memory is external to the controller
(b) The Program memory is internal to the controller
(c) The Program memory is either internal or external to the controller
14. How many program fetches occur per machine cycle?
(a) 1 (b) 2 (c) 3 (d) 4
15. How many 'program memory·fetches' are skipped during the execution ofMOVXinstruction?
(a) 1 (b) 2 (c) 3 (d) 4
16. The Address Latch Enable (ALE) signal is asserted how many times in a machine cycle?
(a) 1 (b) 2 (c) 3 . · ·(d) 4
17. How many times the ALE signal is skipped during the execution of a MOVXinstruction?
(a) 1 (b) 2 (c) 3 (d) 4
18. Which of the following is true about MOVC instruction
(a) Used for reading from Program memory (b) Uses In_dexed Addressing technique
(c) Both a & b (d) None of these
19. The content of Accumulator is FFH and the Carry Flag is in the cleared state. What will be the contents of Accu-
mulator and carry flag after executing the instruction ADD A, #1
(a) Accumulator 0 lH; Carry flag = 1 (b) Accumulator = 0 lH; Carry flag 0
(c) Accumulator OOH; Carry flag= 0 (d) Accumulator= OOH; Carry flag 1
20. Accumulator register contains OFH and the Carry flag CY is in the set state. Wh~t will be the state of Carry flag
after executing the instruction ADD A, #OFOH
(a) 1 (b) 0 (c) Indeterminate
21. The content of the accumulator is FFH and the Carry flag is in the cleared state. What will be the contents of the
accumulator and carry flag after executing the instruction ADDC A,#I
(a) Accumulator= OlH; Carry flag= 1 (b) Accumulator= OlH; Carry flag 0
(c) Accumulator OOH; Carry flag = 0 (d) Accumulator= OOH; Carry flag
C
l
22. · Accumulator register contains OFH and the Carry flag CY is in the cleared state. What will be .the contents of Carry
!' flag and Accumulator after executing the instruction SUBB A, #OFOH
J (a) Accumulator ElH; Carry flag= 1 (b) Accumulator= ElH; Carry flag 0
l -~
(c) Accumulator 1FH; Carry flag = 0 (d) Accumulator = lFH; Carry flag 1
23. Accumulator register contains FOH and the Carry flag CY is in the cleared state. What will be the contents of the
Carry flag and the accumulator after executing the instruction SUBB A,#OFH
(a) Accumulator ElH; Carry flag I (b) Accumulator= EIH; Carry flag= 0
(c) Accumulator I FH; Carry flag O (d) Accumulator = 1FH; Carry flag= 1
24. Accumulator register contains 0FFH and the B register contains 02H. What will be the contents of the Accumula-
tor and B register after executing the instruction MUL AB
(a) Accumulator OFER; B OlH (b) Accumulator= OOH; B = OFER
(c) Accumulator OFER; B OOH • (d) Accumulator= 0lH; B = 0FEH
25. Accumulator register contains 0FFH, B register contains 02H and the Carry flag is in the cleared state. What will
be the contents of the Carry flag and Overflow flag after executing the instruction MUL AB
(a) Carry flag 1; Overflow flag 0
(b) Carry flag 0; Overflow flag = Remains same as the previous value
(c) Carry flag 1; Overflow flag = 1
(d) Carry flag O; Overflow flag= 1
26. Accumulator register contains OFFH, B register contains 02H and the Overflow flag is in the cleared state. What .
will be the contents of the Carry flag and Overflow flag after executing the instruction MUL AB
(a) -Qarry flag remains same as the previous value; Overflow flag= 0
(b) Carry flag remains same as the previous value; Overflow flag= 1
(c) Carry flag ::iJ.;_Overflow flag= I
(d) Carry flag 0; Overflow flag= I
 Introduction to Embedded Systems

27. Accumulator contains OFFH and the B Register contains 02H. What will be the contents of the accumulator and B
register after executing the instruction DIV AB
(a) Accumulator OlH; B 7FH (b) Accumulator= 7FH; B OlH
(c) Accumulator = 7FH; B OOH (d) Accumulator= OOH; B = 7FH
28. Accumulator register contains OFFH and the B register contains OH. What will be the contents of the accumulator,
B register and Overflow flag after executing the instruction DIV AB
(a) Accumulator= OOH; B = OOH; Overflow flag= 1
(b) Accumulator = OFFH; B = OOH; Overflow flag = 0
(c) Accumulator= Undefined; B = Undefined; Overflow flag I
(d) Accumulator = Undefined; B = Undefined; Overflow flag 0
29. Accumulator register contains 0FFH and the Carry flag CY is in the cleared state. What will be the contents of
Carry flag and the accumulator after executing the instruction INC A
(a) Accumulator= OOH; Carry flag= I (b) Accumulator= OOH; Carry flag= 0
(c) Accumulator OIH; Carry flag= 0 (d) Accumulator OIH; Carry flag= 1
30. Accumulator register contains OOH and the Carry flag CY is in the cleared state. What will be the contents of Carry
flag and Accumulator after executing the instruction DEC A
(a) Accumulator= OOH; Carry flag I (b) Accumulator OOH; Carry flag 0
(c) Accumulator= FFH; Carry flag O (d) Accumulator= FFH; Carry flag = 1
31. DPTR contains 2050H. What will be the content of DPTR after executing the following instructions
XCH A,DPL
DEC A
CJNE A, #OFFH, skip_dee
DEC DPH
skip_dec:
XCH A,DPL
(a) 2050H (b) 2049H (c) 2051H (d) 204FH
32. Accumulator register contains 0FH. What will be the content of the accumulator after executing the instruction DA A
(a) 0FH (b) IS H (c) 15 (d) OOH
33. Accumulator register contains the BCD number 28. What will be the content of the accumulator after executing the
instruction ADD A, #12H
(a) 40H (b) 3AH (c) 40 (d) None of these
34. Accumulator register contains the BCD number 28. What will be the content of the accumulator after executing
the following instructions
ADDA,#I2H
DAA
(a) 40H (b) 3AH (c) 40 (d) None of these
35. Accumulator register contains 0FH. What will be the content of the accumulator after executing the instruction
ORLA, #OFOH
(a) OFH (b) F0H (c) FFH (d) OOH •
36. Accumulator register contains 0FH. What will be the content of the accumulator after executing the instruction
ANLA, #OFOH
(a) OFH (b) F0H (c) FFH (d) OOH
37. Accumulator register contains 0AAH. What will be the content of the accumulator after executing the instruction
XRLA, #OD5H
(a) AAH (b) 7FH (c) D5H (d) FFH
38. Accumulator register contains 7FH and carry flag is in the set state. What will be the contents of Accumulator and
carry flag after executing the instruction CLR A
(a) Accumulator= 7FH; Carry flag 0. (b) Accumulator= 7FH; Carry ffag
(c) Accumulator = OOH; Carry flag = 0 (d) Accumulator = OOH; Carry flag I
 Programming the 80S1 Microcontroller

39. What changes will happen on executing the instruction CLR OOH
(a) The code memory location OOH becomes OOH
(b) The data memory location OOH becomes OOH
(c) The external data memory location OOH becomes OOH
(d) The LS Bit of the data held by data memory location 20H becomes 0
40. Accumulator register contains OFH and carry flag is in the set state. What will be the contents of the Accumulator
and carry flag after executing the instruction CPL A
(a) Accumulator = OFH; Carry flag "" 0 (b) Accumulator d. OFH; Carry flag = 1
(c) Accumulator= FOH; Carry flag O (d) Accumulator= FOH; Carry flag= 1
41. Accumulator register contains O1H and carry flag is in the set state. What will be the contents of Accumulator and
carry flag after executing the instruction RL A
(a) A~cumulator- = 02H; Carry flag = 0 (b) Accumulator = 02H; Carry flag = 1
(c) Accumulator= 80H; Carry flag = 0 (d) Accumulator = 80H; Carry flag = l
42. Accumulator register contains O1H and·carry flag is in the set state. What will be the contents of Accumulator and
carry flag after executing the instruction RLC A
(a) Accumulator 02H; Carry flag O (b) Accumulator= 02H; Carry flag= 1
(c) Accumulator= 03H; Carry flag = 0 (d) Accumulator 03H; Carry flag == 1
43. Accumulator register contains OlH and carry flag is in the set state. What will be the contents of the accumulator
and carry flag after executing the instruction RR A
(a) Accumulator= 02H; Carry flag= 0 (b) Accumulator= 02H; Carry flag= 1
(c) Accumulator 80H; Carry flag= 0 (d) Accumulator 80H; Carry flag-= 1
44. Accumulator register contains OlH and carry flag is in the set state. What will be the contents of the accumulator
and carry fl~g after executing the instruction RRC A
(a) Accumulator= 80H; Carry flag= 0 (b) Accumulator 80H; Carry flag= 1
(c) Accumulator.= 03H; Carry flag O (d) Accumulator= 03H; Carry flag = 1
45. Accumulator register contains 5FH. What will be the content of the accumulator after executing the instruction
SWAPA
(a) OOH (b) F5H (c) 5FH (d) OOH
46. What changes will happen on executing the instruction CPL OOH
(a) The code memory location OOH becomes OOH
(b) The data memory location OOH becomes OOH
(c) The external data memory location OOH becomes OOH
(d) The LS Bit of the data held by data memory location 20H is complemented
47. The carry bit is in the set state and the port status bit PLO is in the cleared state. What J,jll be the values of Carry
bit and Pl.O after executing the instruction ANL C, IP 1.0
(a) Carry flag= O; PLO O (b) Carry flag= O; PLO 1
(c) Carry flag l; Pl.O =0 (d) Carry flag l; PLO= 1
48. The Carry bit is in the cleared state and the Port status bit Pl.O is in the cleared state. What will be the values of
Carry bit and PLO after executing the instruction ORL C, /PJ.O
(a) Carry flag= O; Pl.O O (b) Carry flag= O; Pl.O 1
(c) Carry Flag= l; Pl.O O (d) Carry flag l; Pl.O = l
49. Which of the following Jump instruction is the optimal instruction if the offset (relative displacement ofjump loca-
tion from the current instruction location) of the jump location is greater than 127 and less than-128 and is within
the same 2K block of the current instruction
(a) AJMP (b) SJMP (c) LJMP (d) All of these
SO. The program execution needs to be diverted_ to a location within the 2K memory block of the curre~t instruction
and the 11 Least significant bits of the code memory _address to w4ich the jump is intended is 050FH>fhe-4JMP
instruction is used for implementing the jump. What is the machine code for implementing the AIM~ instruction
for jumping to the specified location? ,, \
(a) OlH, OFH, 05H (b) OlH, 05H, OFH (c) AIH, OFH (d) None of these
 Introduction to Embedded Systems

51. Which of the following Jump instruction encodes the jump location as absolute memory address
(a) SJMP (b) AJMP (c) LJMP (d) All of these
(e) only (b) and (c)
52. All the conditional branching instructions specify the destination address by
'i (a) Relative offset method (b) Absolute address method
(c) Either relative or absolute address method (d) None of these

ell Review Questions ]

1. Explain with examples the different addressing modes supported by 8051 CPU
2. What is the difference between Register Instructions and Register Specific Instructions? Give an example for
each
3. What is the difference between Immediate addressing and Indexed addressing? State where these addressing tech-
niques are used. Give an example for each.
4. What is Data transfer instruction? Explain the different data transfer instructions supported by 8051 CPU
5. Explain the arithmetic operations/instructions supported by 8051 CPU
6. Accumulator register contains 0lH and Carry flag is in the state. What will be the contents of accumulator and
Carry flag on executing the instruction
RRA
RRCA
7. Examine the following piece of code and explain whether the program will work in the expected way. Justify your
statement
MOVPl.0, PL2
8. In the following code snippet, the jump location is intended to a memory address with offset beyond+ 127. Suggest
a workaround to solve this issue
CJNE A, #01 H, JUMP_HERE
.
;The relative address oflabel' JUMP_HERE 'is greater than 127 JUMP_HERE: XCH A,B
9. Explain the stack memory related data transfer instructions in detail
10. Explain the data exchange instructions in detail with examples
11. Explain the timing diagram for the MOVX instruction execution when the program memory is internal to the
processor
12. Explain the difference between ADD, ADDC and DAA instructions. Explain the significance of DAA instruction?
13. Explain the instruction for division operation. How is a divide by zero condition handled in the 8051 architecture?
14. Explain the different logical operations supported by 8051 and the corresponding instruction in detail
15. Explain the different Boolean instructions supported by 8051 ·
16. Explain the different unconditional program control transfer instructions supported by 8051
1'7. Explain the different conditional program control transfer instructions supported by 8051
18. Explain the implementation of switchO case statement using jump tables
19. The 8051 status register doesn't contain a zero flag. Explain.how the 8051 architecture implements .the Jump on
zero and Jump on non-zero conditions
20. Explain the difference between LCALL and ACALL for subroutine invocation? Which one is faster in execution
and why?
21. Explain the difference between RET and RETI instructions
22. Explain the different types of jumps [supported by 8051 architecture. Which one fs, faster ih execution and why?

.
'"

Programming the BOS1 Microcontroller

Lab Assignments
lookup table with . sis stored in cooememoryfocation ~tartihgrrJ~J·
....... .· ~ble . ·. ·
f6t;{ •' .. ····;,~i;witf•J . :c
ig1!,:;
~9e't
1~ri:~,
te· :the
. .· . . . ze anil performance
000.0H
JB . ,PLO, FOR(_SET
MOVA, #50H
· ·:LJM? SKIP
-,~
SET,;" CLR Pl . 0
,

LCALL ✓ DELAY
50H

, :/NOP
RET
~ssembly lfll1gu,ageptggram.~i11g \ipier int~rrupt for ge11er~ting~
.9'., pie.o~cilfatotfrequ~.ri~y'a,pgFedit? :t6e,:,iliicf6cont;oF~r•is ·f::r:QOMHz .•. . .
Wnte··a 80~1·. •as~~mllly.1ang#agiprograin::for,genf1rati~g• a·~., Wi Sq{!a~e w,
oscillator frequency applied.tci'them,.icioc::,nttoll~rii"12:t1p Mil~-"•::·'..· ..... ;(;t'l
Write a'8051 :Asse1rtbly langu,age program
!O •generitte tbefiponatci ;&ecy~~ .
·_number whose.Fibonacci numbetis tobetalculatedjs receiyed fromthei-h.w·
· :.a PC,tQwhi~hthe mjtrocontrolleris .int~rfacedJ)pbn receiving the;n,ti1111:>~ifto,,
the Fibonacci series for the nuniber is generated and it is sent Jo the hyper te ·. ·
· PC. The program also,.inserts. the character:,' to sepai;ate the two sonsecutive n.'\ini.·
it. The numbers are sent with their corresponding ASCII value (e.g. 0 is.s,~p.t ~s- ,
tion parameter settings for both hyper tenninal application and micrqcontrolle,r ,prog
start bit, 8 data bits, i stop bit, No parity. Use a crystal resonato~ with frequency1 I'.O
microcontroller hardware.
7. Write a 8051 assembly language program to find the largest number from an array oflQ
located in the data memory and the start address of the array is 20H. .
8. Write a 8051 assembly language program to generate a PWM signal of ON time 100 hlitrq~e'edncisln.od~ty

I
cycle of39.06%, at port pin PLO / .: ;}.;r.> , · ,
9. Explain with code snippet how the 8051 timer can be used for the measurement of the width of~n unknown
pulse ·. •·v;:~
10. It is required by an experimental setupito count the number of pulses arrived during a tin1e_pfri99 qf,~0;millisec-·
onds. Explain with code snippets how it can'be implemented using the 8051 timers. · · ···
In the traditional embedded system development approach, the hardware software partitioning is done
at an early stage and engineers from the software group take care of the software architecture develop-
ment and implementation, whereas engineers from the hardware group are responsible for building the
hardware required for the product. There is less interaction between the two teams and the development
happens either serially or in parallel. Once the hardware and software are ready, the integration is per-
formed. The increasing competition in the commercial market and need for reduced 'time-to-market'
the product calls for a novel approach for embedded system design in which the hardware and software
1

are co-developed instead of independently developing both.

During the co-design process, the product requirements captured from the customer are converted
into system level needs or processing requirements. At this point of time it is not segregated as either
hardware requirement or software requirement, instead it is specified as furictional requirement. The
system level processing requirements are then transferred into functions which can be simulated and
verified against performance and functionality. The Architecture design follows the system design. The
partition of system level processing requirements into hardware and software takes place during the ar-
chitecture design phase. Each system level processing requirement is mapped as either hardware and/or
\
 Hardware Software Co-Design and Program Modelling

software requirement. The partitioning is performed based on the hardware-software trade-offs. We will
discuss the various hardware software tradeoffs in hardware software co-design in a separate topic. The
architectural design results in the detailed behavioural description of tpe hardware requirement and the
definition of the software required for the hardware. The,processing requirement behaviour is usually
captured using computational models and ultimately the models representing the software processing
requirements are translated into firmware implementation using programming languages.

The hardware software co-design is a problem statement and when we try to solve this problem state-
ment in real life we may come across multiple issues in the design. The following section illustrates
some of the fundamental issues in hardware software co-design.
S.electing the model In hardware software co-design, models are used for capturing and describing
the system characteristics. A model is a formal system consisting of objects and composition rules. It is
hard to make a decision on which model should be followed in a particular system design. Most often
designers switch between a variety of models from the requirements specification to the implementation
aspect of the system design. The reason being, the objective varies with each phase; for example at the
'specification stage, only the functionality of the system is in focus and not the implementation infQrma-
tion. When the design moves to the implementation aspect, the information about the system compo-
·. · nep.ts is revealed and the designer has to switch to a model capable of capturing the system's structure.
· We will discuss about the differen.t models in a later section ,0f this chapter.
Selecting the Architecture A model only captures the system characteristics and does not provide
information on 'how the system can be manufactured?''.' The architecture specifies how a system is
· going to implement in terms of the number and types of different components and the interconnec-
tion among them. Controller architecture, Datapath Architecture, Complex Instruction Set Computing
(CISC), Reduced Instruction Set Computing (RISC), Very Long Instruction Word Computing (VLIW),
Single Instruction Multiple Data (SIMD), Multiple Instruction Multiple Data (MIMD), etc. are the
commonly used architectures in system design. Some of them fall into Application Specific Architec-
ture Class (like controller architecture), while others fall into either_general purpose architecture class
(CISC, RISC, etc.) or Parallel processing class (like VLIW, SIMD, MIMD, etc.).
t The controller architecture implements the finite state machine model (which we will discuss in a
·- later section) using a state register and two combinational circuits (we will discuss about combinational
circuits in a later chapter). The state register holds the present state and the combinational circuits imple-
e ment the logic for next state and output. •
The datapath architecture is best suited for implementing the data flow graph model where the out-
j put is generated as a result of a set of predefined computations on the input data. A datapath represents
:f a channel between the input and output and in datapath architecture the datapath may contain registers,
e counters, register :files, memories and ports along with high speed arithmetic units. Ports connect the
d datapath to/multiple buses. Most of the time the arithmetic units are connected in parallel with pipelin-
e ing support for bringing high performance.
The Finite State Machine Datapath (FSMD) architecture combines the controller architecture with
If datapath architecture. It implements a controller with datapath. The controller generates the control in-
put whereas the datapath processes the 'data. The datapath contains two types of I/O ports, out of which
one acts as the control port for receiving/sending the ,control signals from/to the controller unit and the
r' .

Introduction to Embedded Systems

second I/O port interfaces the datapath with' external world for data input and data output. Normally the
datapath is implemented in a chip and the I/O pins of the chip acts as the data input output ports for the
chip resident data path.
The Complei Instruction Set Computing (CISC) architecture uses an instruction set representing
complex operations. It is possible for a CISC instruction set to perform a large complex operation (e.g.
Reading a register value and comparing it with a given value and then transfer the program execution
to a new address location (The CJNE instruction for 8051 ISA)) with a single instruction. The use of a
single complexinstruction in place of multiple.simple instructions greatly reduces the program memory
access and program n;iemory size requirement. However it requires additional silicon for implementing
microcode decoder for decoding the CISC instruction. The datapath for the. CISC processor is com-
plex. On the other hand, Reduced Instruction Set Computing (RISC) architecture uses instruction set
representing simple operations and it requires the execution of multiple RISC instructions to perform a
complex operation. the data path of RISC architecture contains a large register file for storing the op-
erands and output. RISC instruction set is designed to operate on registers. RISC architecture supports
extensive pipelining.
The Very Long Instruction Word (VLIW) architecture implements multiple functional units (ALUs,
multipliers, etc.) in the datapath. The VLIW instruction packages one standard instruction per functional
unit of the datapath.
Parallel processing architecture implements multiple concurrent Processing Elements (PEs) and
each processing element may associate a datapath coq.taining register and local memory. Single Instruc-
tion Multiple Data (SIMD) and Multiple Instruction Multiple Data (MIMD) architectures are examples
for parallel processing architecture. In SIMD architecture, a single instruction is executed in parallel
with the help of the Processing Elements. The scheduling-of the instruction execution and controlling of
each PE is performed through a single controller. The SIMD architecture forms the basis of re-configu-
rable processor (We will discuss about re-configurable processors in a later chapter). On the other hand,
the processing elements of the MIMD architecture execute differe,nt instructions at a given point of time.
The MIMD architecture forms the basis of multiprocessor systems. The PEs in a multiprocessor system
communicates through mechanisms like shared memory and message passing.
Selecting the language A programming language captures a 'Computational Model' and maps it
into architecture. There is no hard and fast rule to specify this language should be used for capturing
this model. A model can be captured using multiple programming languages like C, C++, C#, Java, etc.
for software implementations and languages like VHDL, System C, Verilog, etc. for hardware imple-
mentations. On the other hand, a single language can be used for capturing a variety of models. Certain
languages are good in capturing certain computational model. For example, C++ is a good candidate
for capturing an object oriented model. The only pre-requisite in selecting a programming language for
capturing a model is that the language should capture the model easily.
Partitioning System Requirements into hardware and software So far we discussed about the
models for capturing the system requirements and the architecture for implementing the system. From
an implementation perspective, it may be possible to implement the system requirements in either hard-
ware or software (firmware). It is a tough decision making task to figure out which one to opt. Various
hardware software trade-offs are used for making a decision on the hardware-software partitioning. We
will discuss them in detail in a later section of this chapter.
 Hardware Software Co-Design and Program Modelling

Data Flow Graph (DFG) model, State Machine model, Concurrent Process model, Sequential Program
model, Object Oriented model, etc. are the commonly used computational models in embedded system
design. The following sections give an overview of these models.

7.Z.1 Data Flow Graph/Diagram (DFG) Model

The Data Flow Graph (DFG) model translates the data processing requirements into a data flow graph .
. The Data Flow Graph (DFG) model is a data driven model in which the program execution is deter-
mined by data. This_ model emphasises on the data and operations on the data which transforms the
input data to output data. Indeed Data Flow Graph '-
(DFG) is a visual model in which the operation on a f
C
I

the data (process) is represented using a block (circle)

and data flow is represented using arrows. An inward
arrow to the process (circle) represents input data and Data flow node
.an outward arrow from the process (circle) represents
output data in DFG notation.
Embedded applications which are computational
intensive and data driven are modeled using the DFG
model. DSP applications are typical examples for
it. Now let's have a look at the implementation of a
DFG. ·suppose one of the functions in our application· y
contains the computational requirementx =a+ b; and
y x c. Figure 7.1 illustrates the implementation of
a DFG model for implementing these requirements.
In a DFG model, a data path is the data flow path from input to output. A DFG model is said to be
acyclic DFG (ADFG)if it doesn't contain multiple values for the input variable and multiple outp.ut val-
ues for a given set of input(s). Feedback inputs (Output is fed back to Input), events, etc. are examples
for non-acyclic inputs. A DFG model translates the program as a single sequential process execution.

7.2.2 Control Data Flow Graph/Diagram (CDFG)

We have seen that the DFG model is a data driven model in which the execution is controlled by data
and it doesn't involve any control operations (conditionals). The Control DFG(CDFG) model is used
for modelling applications involving conditional program execution. CDFG models contains both data
operations and control operations. The CDFG uses Data Flow Graph (DFG) as element and conditional
(constructs) as dec.ision makers. CDFG contains both data flow nodes and decision nodes, whereas DFG
contains only data flow nodes. Let us have a look at the implementation of the CDFG for the following
requirement.
If flag 1, x =a+ b; else y = a b;
This requirement contains a decision making process. The CDFG model for the same is given in
Fig. 7.2.
The control node is represented by a 'Diamond' block which is the decision making element in a
normal flow chart based design. CDFG translates the requirement, which is modeled to a concurrent
process model. The decision on which process is to be executed is determined by the control node.
 introduction to Embedded Systems

A real world example for modelling the embedded ap-

plication using CDFG is the capturing and saving of the
image to a format set by the user in a digital still camera
where everything is data driven starting from the Analog
Front End which converts the CCD sensor generated ana- Control node
log signal to Digital Signal and the task which stores the
data from ADC to a frame buffer for the use of a media
processor which performs various operations like, auto
correction, white balance adjusting, etc. The decision on,
in which format the image is stored (formats like JPEG, Data flow node
TIFF, BMP, etc.) is controlled by the camera settings, con-
figured by the user. ·

7 .2 .3 State Machine Model

The State Machine model is used for modelling reactive
or event-driven embedded systems whose processing @~ef~tJ~) ·
behaviour are dependent on state transitions. Embedded
systems used in the control and industrial applications are ,
typical examples for event driven systems. The State Machine model describes the system behaviour
with 'States', 'Events', 'Actions' and 'Transitions'. State is a repr,esentation of a current situation. An
event is an input to the state. The event acts as stimuli for state transition. Transition is the movement
from one state to another. Action is an activity to be performed by the state machine.
A Finite State Machine (FSM) model is one in w~ich the number of states are finite. In other words
the system is described using a finite number of possible states. As an example let us consider the de-
sign of an embedded system for driver/passenger 'Seat Belt Warning' in an automotive using the FSM
model. The system requirements are captured as.
1. When the vehicle ignition is turned on and the seat belt is not fastened within 10 seconds of igni-
tion ON, the system generates an alarm signal for 5 seconds.
2. The Alarm is turned off when the alarm time (5 seconds) expires or if the driver/passenger fastens
the belt or if the ign,ition switch is turn~d off1 whichever happens first.
Here the states are 'Alarm Off', 'Waiting' and 'Alarm On' and the events are 'Ignition Key ON',
'Ignition Key OFF', 'Timer Expire', 'Alarm Time Expire' and 'Seat Belt ON'. Using the FSM, the sys-
tem requirements can be modeled as given irt Fig. 7.3.
The 'Ignition Key ON' event triggers the 10 second timer and transitions the state to 'Waiting'. If a
'Seat Belt ON' br 'Ignition Key OFF' event occurs during the wait state, the state transitions into' Alarm
Off'. When the wait timer expires in the waiting state, the event 'Timer Expire' is generated and it tran-
sitions the state to 'Alarm On' from the 'Waiting' state. The 'Alarm On' state continues until a 'Seat Belt
ON' or 'Ignition Key OFF' event or 'Alarm Time Expire' event, whichever occurs first. The occurrence
of any of these events transitions the state to 'Alarm Off'. The wait state is implemented using a timer.
The timer also has certain set of states and events for state transitions. Using the FSM model, the timer
can be modeled as shown in Fig. 7.4. ,
As seen from the FSM, the timer state can be either 'IDLE' or 'READY' or 'RUNNING'. During
the normal condition when·the timer is not running, it is said to be in the 'IDLE' state. The timer is said
to be in the 'READY' state when the timer is loaded with the count corresponding to the required time
 Hardware Software Co-Design and Program Modelling

Ignition Key ON

Ignition Key OFF

Seat Belt ON

Event: Load Timer

Action: Timer Count= New Count
ven
,4.
·. Sto
'tio
o,- h~:,s,
¾lJe0
ltt'1 o
IJtel"tq
'Pt

delay. The timer remains in the 'READY' state until a 'Start Timer' event occurs. The timer changes
its state to 'RUNNING' from the 'READY' state on receiving a 'Start Timer' event and remains in the
'RUNNING' state until the timer count expires or a 'Stop Timer' even occurs. The timer state changes
to 'IDLE' from 'RUNNING' on receiving a 'Stop Timer' or 'Timer Expire' event.

Design an automatic tea/coffee vending machine based on FSM model for the following requirement.
The tea/coffee vending is initiated by user inserting a 5 rupee coin. After inserting the coin, the user can either select
'Coffee' or 'Tea' or press 'Cancel' to cancel the order and take back the coin.
Th.e FSM representation for the above requirement is given in Fig. 7.5.
In its simplest representation, it contains four states namely; 'Wait for coin' 'Wait for User Input', 'Dispense Tea' and
'Dispense Coffee'. The event 'Insert Coin' (5 rupee coin insertion), transitions the state to 'Wait for User Input'. The
system stays in this state until a user input is received from the buttons 'Cancel', 'Tea' or '.Coffee' (Tea and Coffee are
the drink select button). If the event triggered in 'Wait State' is 'Cancel' button press, the coin is pushed out and the state
·. ·transitions to 'Wait for Coin\ If the event received in the 'Wait State' is either 'Tea' button press, or 'Coffee' button press,
the state changes to 'Dispense Tea' and 'Dispense Coffee' respectively. Once the coffee/tea vending is over, the respective
I'
I
j'

·Introduction to Embedded Systems

Event: Insert Coin State A: Wait for coin

Action: ok State B: Wait for user input
Event: Cancel Butto State C: Dispense tea
State D: Dispense coffee

states transitions back to the 'Wait for Coin' state. A few modifications like adding a timeout for the 'Wait State' (Cur-
rently the 'Wait State' is infinite; it can be re-designed to a timeout based 'Wait State'. If no user input is received within
the timeout period, the coin is returned back and the state automatically transitions to 'Wait for Coin' on the timeout
event) and capturing another events like, 'Water not available', 'Tea/Coffee Mix not available' and changing the state to
an 'Error State' can be added to enhance this design. It is left to the readers as exercise.

Design a coin operated public telephone unit based on FSM model for the following requirements.
1. The calling process is initiated by lifting the receiver (off-hook) of the telephone unit
2. After lifting the phone the user needs to insert a 1 rupee coin to make the call.
3. If the line is busy, the coin is returned on placing the receiver back on the hook (on-hook)
4. If the line is through, the user is allowed to talk till 60 seconds and at the end of 45 th second, prompt for inserting
another 1 rupee coin for continuing the call is initiated
5. If the user doesn't insert another 1 rupee coin, the call is terminated on completing the 60 seconds time slot.
6. The system is ready to accept hew call request when the receiver is placed back on the hook (on-hook)
7. The system goes to the 'Out of Order' state when there is a line fault.
The FSM model shown in Fig. 7:6, is a simple representation'and it doesn't take care of scenarios like, use~ doesn't
insert a coin within the specified time after lifting the receiver, user inserts coins other than a one rupee etc. Handling
these scenarios is left to the readers as exercise.
Most of the time state machine model translates the requirements into sequence driven program and it is difficult to
implement concurrent processing with FSM. This limitation is addressed by the Hierarchical/Concurrent Finite State
Machine model (HCFSM). The HCFSM is an extension of the FSM for supporting concurrency and hierarchy. HCFSM
extends the conventional state diagrams by the AND, OR decomposition of States together with inter level transitions
and a broadcast mechanism for communicating between concurrent processes. HCFSM uses statecharts for capturing the
states, transitions, events and actions. The Harel Statechart, UML State diagram, etc. are examples for popular statecharts
used for the HCFSM modelling of embedded-systems. In statecharts, the state is usually represented using geometric
shapes like rounded rectangle, rectangle, ellipse, circle, etc. The Hare! Statechart uses a rounded rectangle for represent-
ing state. Arrows are used for representing the state transition and they are marked with the event associated with the state
transition. Sometimes an optional parenthesized condition is also labeled with the arrow. The condition specifies on what
 Hardware Software Co-Design and Program Modelling

State A: Ready State E: Call in progress

State B: Wait for coin State F: Call terminated
State C: Wait for number State G: Unable to make call
State D: Dialling State H: Invalid m,tmber input
State I: Out of order

basis the state transition happens at the occurrence of the specified event. Lots of design tools are available for state rria-
chine and statechart based system modelling. The IAR visua!STATE (http://www.iar.coJlllwebsitel/1.0.1.0/371/l/index.
php) from IAR systems is a popular visual modelling tool for embedded applications.

7.2.4 Sequential Program Model·

In the sequential programming Model, the functions or processing requirements are executed in se-
quence. It is same as the conventional procedural programming. Here the program instructions are
iterated and executed conditionally and the data gets transformed through a series of operations. FSMs
are good choice for sequential program modelling. Another important tool used for modelling sequen-
tial program is Flow Charts. The FSM approach represents the states, events, transitions and actions,
whereas the Flow Chart models the execution flow. The execution of functions in a sequential program
model for the 'Seat Belt Warning' system is illustrated below.
 i
l
I
1.1·

!
~
\
!
Introduction to Embedded Systems

Figure 7. 7 illustrates the flow chart approach for model-

ling the 'Seat Belt Warning' system explained in the FSM
modelling section. Wait for 10 Seconds

7 .2.5 Concurrent/Communicating
Process Model
The concurrent or communicating process model models
concurrently executing tasks/processes. So far we discussed
about the sequential execution of software programs. It
is easier to implement certain requirements in concur-
rent processing model than the conventional sequential Set Timer for 5 Seconds
execution. Sequential execution leads to a single sequen- Start Alarm
tial execution of task and thereby leads to poor processor
utilisation, when the task involves I/O waiting, sleeping
for specified duration etc. If the task is split into multiple
subtasks, it is possible to tackle the CPU usage effectively,
NO
when the subtask under execution goes to a wait-or sleep
mode, by switching the task execution. However, concur-
rent processing model requires additional overheads in
task scheduling, task synchronisation and communication.
As an example for the concurrent processing model let us
examine how we can implement the 'Seat Belt Warning'
system in concurrent processing model. We can split the
tasks into:
1. Timer task for waiting 10 seconds (wait timer task)
2. Task for checking the ignition key status (ignition Stop Alarm
key status monitoring task)
3. Task for checking the seat belt status (seat belt status End
monitoring task)
·.~~~~~~1".~P~,1 !~:\' Sei;lt
mg·svstem ·· · · · 1
 Hardware Software Co-Design and Program Modelling

4. Task for starting and stopping the alarm (alarm control task)
5. Alarm timer task for waiting 5 seconds (alarm timer task)
We have five tasks here and we cannot execute them randomly or sequentially. We need to synchro-
nise their execution through some mechanism. We need to start the alarm only after the expiration of
the 10 seconds wait timer and that too only if the seat belt is OFF and the ignition key is ON. Hence
the alann: control task is executed only when the wait timer is expired and if the ignition key is in the
ON state and seat belt is in the OFF state. Here we will use events to indicate these scenarios. The
wait_timer_expire event is associated with 1the timer task event and it will be in the reset state initially
and it is set when the timer expires. Similarly, event,s ignition_on and ignition_ojf are associ~ted with
the task ignition key status monitoring and the eve;nts seat_belt_on and seat_belt_ojf are associated with
the t,ask seat belt status morning. The events ignit'ion_off and ignition_on are set and reset respectively
when the ignition key status is OFF and reset and set respectively when the ignition key status is ON, by
the ignitiqn key status monitorihg task. Similarly the events seat_belt_ofjand seat_belt_on ate set and
reset respectively when the seat belt status is OFF and reset and set respectively when the seat belt status
is ON, by the seat belt status monitoring task. The events alarm_timer_start and alarm_timer expire are
associated with the alarm timer task. The alarm_timer_start event will be in the reset state initially and
it is set by ~h_e_alarm co~t~ol ta.sk 11i'~en the ala~ is start~d. The alarm timer_expire ev~nt will be !n the
resefsfii.Te-Imt1aHy-and.itis..__se.t wh,¥ 1the alarm timer expires. The alarm control task waits for the signal-
ing of the event wait_timer expir~ and starts the alarm timer and alarm if both the events ignition_on
and seat_belt_off are in the set state when the event llfait_timer_expire signals. If not the alarm control
task simply completes its execution and returns. In case the alarm is started, the alarm control task waits
f?r the_ signalling of a~y one of the events a!arm_timer:_expire or ignition_off or ~eat_belt_on. Up?n
signallmg any one of tHese events, the alarm 1s stopped and the alarm control task simply completes its
eX:ecutiori an<ireturns. Figure 7.8 illustrates the same.
It should be noted that the method explained here is just one way of implementing a concurrent mod-
el for the 'Seat Belt Warning' system. The intention is just to make the readers familiar with the concept
of multi tasking and task communicat1on/synchronisation. There may be other ways to model the same
requirements. It is left to the readers as exercise. The concurrent processing model is commonly used
for the modelling of 'Real Time' systems. Various techniques like 'Shared memory', 'Message Passing',
'Events.'; etc. are used for communication and synchronising between concurrently executing processes.
We will discuss these techniques in a later chapter.

7.2.6 Object~Oriented Model

l The object-oriented model is an object basedmodel for modelling system requirements. It disseminates
a complex software requirement into simple well defined pieces called objects. Object-oriented model
brings re-usability, maintainability and productivity in system design. In the object-oriented modelling,
object is an entity used for representing. or modelling a particular piece of the system. Each object is
characterised by a set of unique behaviour and state. A class is an abstract description of a set of objects
· and-itcan be considered as a 'blueprint' of an object. A class represents the state of an object through
member variables and object behaviour through member functions. The member variables and member
functions of a class can be private, public or protected. Private member variables and functions are
accessible only within the class, whereas public variables and functions are accessible within the class
as well as outside the class. The p~tected variables and functions are protected from external access.
However classes derived from a parent class can also access the prote1cted member functions and
variables. The concept of object and class brings abstraction, hiding;:g1d protection.
 Introduction to Embedded Systems

(a)

Auirin Coktrol
WaitJof:th~}1gtz,
wljit)im~r'}_fipf,: ..
ifl(f~iti9h::,'o_n' ~:&;;
{ >:,: ·: y ';. :; .
', < ,·

s,arJ W&woi . ::>

·~ehE.veht tildM{ .
W~itJdr the.t~:
aianii tzmer': e>;
~.- ig~it(on)JJ;, s11rit
StopAlarm(}; ..
}

Igniiior/$eat u.-,.'r·,;•.•J"...•·,·
Task
w}1ile(JJ 'f ...
if (Seat Belt ON)
{
'---,1----1 Set Event seat_bel(_pn;
Reset Event seat_belt_off;
}
else
{
Set Event seat_belt_ojf;
Reset Event seat belt 'on;
} - -
}
-----------"
(b)

(Fig.7.8) ~~lf;!itt~:!~~f-~~at Be!t\\,',~z#g System' (h) Concurrent proces~_inQ~?~ ~~~~~.t~~}!~~~!~lt.

;w~~nif:,vstem' c:. ·:>% :> 11. · • ,. 7
,\•, ?: ,, .<\

Unified Modelling Language (CT.ML) is a visual modelling language for Object Oriented Design (OOD).
UML helps in all phases of system design through a set of unique diagrams for requirements capturing,
designing and deployment.
 Hardware Software Co-Design and Program Modelling

7.3.1 UML Building Blocks

'Things', 'Relationships' and 'Diagrams' are the fundamental building blocks ofUML.
7.3.1.1 Things A 'Thing' is an abstraction of the UML model. The 'Things' in UML are classified
into:
Structural things: Represents mostly the static parts of a UML model. They are also known as 'classi-
fiers'. Class, interface, use case, use case realisation (collaboration), active class, component and node
are the structural things in UML.
Behavioural things: Represents mostly the dynamic parts of a UML model. Interaction, state machine
and activity are the behavioural things in UML.
Grouping things: Are the organisational parts of a UML model. Package and sub-system are the group-
ing things in UML.
Annotational things: Are the explanatory parts of a UML model. Note is the Annotational thing in
UML.
The table given below gives a snapshot of various strnctural, behavioural, grouping andAnnotational
things in UML.

~i};1~iM1#f1,;;·:{l~l.11¥if~t#•fif;1Nf:5.,, · · .•:'.i2t{i:l1;itii.i?i!~~~:
l< ~: - •r . . . Class . . A temp1aie ., 'b1J~ ~ sifof
the same . . .
· :,:;'!Ji~anti~~
!, ~bjyct.

A computational resource existing ;~f rt1it

Represented using a cube with name.
., )>.. ame ,
r:f•
 Introduction to Embedded Systems

Alarm I Alarm I Timer

! -Period
'/ +Set Time()
\+Start() +Startg
+Stop()
+Stop(
(a) (b) (c)

( Fig. 7.9) ~a) Th~ _1Uarm.piass. (b) .· State _Repres~ntation for 'lU~m ON' statt:;: {c) ~~~:'ft:~bii~f,K,.'".c,, ~'•
interaction for the Seat belt Warning System · , ··· ;f,s,; ;:·, ·•.: _Y•·;

7.3.1.2 Relationships As the name indicates, they express the type of relationship between UML
elements (objects, classes, etc). The table given below gives a snapshot of the various relationships in
UML.

It is a structural relationship d
objects. The associat16n can .
many,Aggregation
. and Com_p
.
', '• .
 Hardware Software Co-Design and Program Modelling

Audio Visual Indicators Alarm

'\+Start()
+Sto

(a) (b)

.,;:~~j~t~~~(~:~~~~al'•t .1~~~}J!~~~~~:!,,,7t~f:~;~f~✓~~~,{:
7.3.1. 3 UML Diagrams UML Diagrams give a pictorial representation of the static aspects, behav-
ioural aspects and organisation and management of different modules (classes, packages, etc.) of the
system. UML diagrams are grouped into Static Diagrams and Behavioural Diagrams.
Static Diagrams Diagram representing the static (structural) aspects of the system. Class Dia-
gram, Object Diagram, Component Diagram, Package Diagram, Composite Structure Diagram and
Deployment Diagram falls under this category. The table given below gives a snapshot of various static
diagrams.

Behavioural Diagrams These are diagrams representing the dynamic (behavioural) aspects of the
system. Use Case Diagram (Fig. 7.11), Sequence Diagram (Fig. 7.12), State Diagram, Communication
 Introduction to Embedded Systems

~
s< SeatBelt

Use case
Alarm

Ignition Key

~
Wait Timer
~
3 OFF
~
I
I
5 Trigger I

Ignition Key Seat Belt

I
I 1 T.rgger
2 Timeout
I 6Timeout
I
I 40N
I

Diagram, Activity Diagram, Timing Diagram and Interaction Overview Diagram areJhe behavioural di-
agrams in UML model. The table given below gives a snapshot of the important behavioural diagrams.
 Hardware Software Co-Design and Program Modelling

. 1.3.2 The UMLTools

1
The tools for building UML based models and diagrams are available from different vendors. Some of
them are commercial and some of them are either free or open source. The table given below gives a
summary of the popular UML modelling tools.

Some of the tools generate the skeletal code (stub) for the classes and application in programming lan-
guages like C++, C#, Java, etc.

l- Certain system level processing requirements may be possible to develop in either hardware or soft-
;, ware. The decision on which one to opt is based on the trade-offs and actual system requirement. For
example, if the embedded system under consideration involves some multimedia coded requirement.
The media codec can be developed in either software. or using dedicated hardware chip (like ASIC or
ASSP). Here the trade-off is performance and re-configurability. A codec developed in hardware may be
much more efficient, optimised with low processing and power requirements. It is possible to develop
the same codec in software using algorithm. But the software implementation need not be optimised for
perfonnance, speed and power efficiency. On the other hand, a codec developed in software is re-usable
and re-configurable. With certain modification it can be configured for other codec implementations,
whereas a codec developed in a fixed hardware (like ASIC/ASSP) is fixed and it cannot be changed.
Memory size is another important hardware software trade-off. Evaluate how much memory is re-
quired if the system requirement under consideration is implemented in software (firmware). Embedded
systems are highly memory constrained ctnd embedded designers_ don't have the luxury of using lavish
t Eclipse is an open source Integrated Development Environment (IDE). Visit www.eclipse.org for more details.
t Multimedia codec is a compression and de-compression algorithmror compressing and de-compression ofraw data media files (audio
and video data)
 Introduction to Embedded Systems

memory for implementing requirements. On the other hand, evaluate the gate count required (Normally
hardware chips are implemented using logic gates and the density of the chip is expressed in terms of the
number of gates used in the design (millions of gates©)), if the required feature is going to implement
in hardware.
Effort required in terms of man hours, if the required feature is going to build in either software or
custom hardware implementation using VHDL or any other hardware description languages and the cost
for each are another important hardware-software trade-off in any embedded system development.
To summarise, the important hardware-software trade-offs in embedded system design are
1. Processing speed aQd perform;mce
2. Frequency of change (Re-cor:i.figurability)
3. Memory size and gate count
4. Reliability .
5. Man hours (Effort) and cost

Summary
' --- "" -/''-->-

✓ Model seJectioti~ Archite~ture selectfon; banguagg sHection;Hardware Softwite parti\i,~iifu. .M

... ·•· thfm~inpointin·th~hafaiare~i.oftwareco-de,sign;:' ,. , . • •. , .·., • J :, .
. l ikmo~~fbap~es ~d:descfibe~'ihl~yst~m ch(iacfe,dstfos. Th~ architectµre ~pe6ifi~f
. ' .· illlplement i~t,ertns 6tthe11umbetJt~dtyp~b~fdi~erihtconipbnentsi~a tlie.· . .
.'✓ i:'.Gb~!fpUer~chiticfur~, ;Pit<1Eafli,iaf6bffo,qttlre?qt\µi~1~xln;ffecti8irser. . ·,.. ··•·,
.. c:,,;.,.Jioil~Set.Cofuput;fog
.::• .. '-"·"'.·•· .... , ... ,-;,-·<··'J:.'7:;::_",
i·· ·: _· .:
(lUSC); Vecy.Jong
,-"·.-<,-,, ..
InstructionWord ~omputing·;eytI\Y),'§Jrig
?. ··i-'~·'.·,,·-·.e···<. -· ,_,."· -~--~,,,; ,-_ ,,_., .. ,"_.. ··~- . . .___
:--},:,Li'.....
.
_...-._,_f.
(SIMD),.·Multiple:In~tnl(?tion Mult,jpl¢,P~tii::(MJMp), et~. ai:e1p.~ ¢oi:µnio~Jyu,sed',(lrclii
:1 · Data Fl ow. G~ph (q FG)Model, .~t~te'Ma9hmeJf)del,' c·onciirr~nt Process Moqel;
:.,ObjectOriented model; etc:~are the ,conunonlyused computational mpdelsin ~nil:>e.
✓ A programming l.µ1guage captures a ·•computational Model' and maps it ~r1,tq·\
captured using' multiple programming languages like C, C++, C#, Java, etc. forsoJtwaieJrrf
langu~ges lik~ ,\lfIDJ:,, System C, Yeril9g, etc. f2r,haf~:Y~ejppl.em~.~!~ti.Qll§;~ ..,,;.. · }irh:;{/''
·;,, The Hierarchical/Concurrent Finite State'Machine Model (HCFSM)is·ari extensioifoff . . . ..
concurrency and hierarchy. HCFSM extends the conventional state diagrams by theANb;5ffd6c6~po~
States together with inter lever transitions and a broadcast mechanism for communicating between:ie6~"
processes .. ···
✓ HCE<SM uses.statecharts for capturing the states, transitions, events and actions., The Hw:~tSR1t~s;J:i.<lrt,.UMJ;;§t~t~
diagram, etc. are examples for popular statecharts for the HCFSM mpdelling (}f embedded systems ·..
✓ In the sequential model, the functions or processing requirements are executed in seq4ence. It.is samea~.!h,e ·
conventional procedural programming . ·. ·
✓ The concurrent or communicating process model models concurrently executing tasks/protesses
✓ The (}bject oriented model is an object based model for modelling system requirements .
✓ Unified ModellingLanguage (UML) is a\lisual modelling language for Object Oriented Design (00D). Things,
Relationships and Diagrams are the fundamental building blocks ofUML ! ..
✓ UML diagrams give a pictorial representation of the static aspects, behavioural aspect~ aijd orgiµµsMi§fffuid
management of different modules. Static Diagrams, Object diagram, Usecase diagram, Sequenc~uiagr,~~;;;ijjt-
echart diagram etc. are the different UML diagrams ·. . : . .
✓ Hardware-Software trade•offs are the parameters used in the decision making of partitioning a system r~q~ire-
ment into either hardware or software. Processing speed, performance, frequency of changes, memory s~e:~d
gate count requirements, reliability, effort, cost, etc. are examples for hardware-software trade-offs · ··· · ·
 Hardware Software Co-Design and Program Modelling

c• Keywords l
Hardware-Software Co-design The modem approach for the interactive 'together' design of hardware ii,n~ ..
firmware for embedded systems
Controller Architecture Architecture imple~enting the Finite State Machine model using a :~taf;{i
. register and ~o·combinational·circuits . ,,; .,
, ioatapathArchitecture Dat~pa,th .· : Architecture implemeritingtheData Flow Graph model .
Athkiel beMeer/the ilip~t and output. Th~ d~ta:patli ina,y'i:o'rittf
. isters, courtters, register files: i;nehioiies and ports along with big
arithn:ie'tic:units ., ' , . ' ' ., ,, '\.~'.,
·. 'Finite State ~adrl;e Datapath Archite~ture,combining thi(controller architecture withdat{l1>,ath aJ~
::(FS$)j(rcnitecture . ......•.. ·.• . ·.. 'ture . . . ' . • .. :,:);.1.::;;
;: CoJllplex1n~tructioo,?Settompµ~ng .): .Architecture·which useitinstruction set representing complex operat1i~if:;;{ '
/((J;JS<:)'Ar~hit~ct~r~' , >;' ,•,r ::, , ', " , ; ·:·';:?''.~~tt2
Reduced Instruction Set Co'rnptiting Architecture which uses instruction set representing simple operatio~~: P/!,
(RISC) Architecture . /:.li ,
Very Long Instruction Word Architecture impleinenting miiltiple functional units (ALUs, niultipfiJcsl;i
(VLIW) Architecture _' ·/etc.)inJlle datapath . . . ,;,:::i
Parallel Processing Architecture'• ·:.: t-kchit~~ture .· i'~plementing. -~ultiple concurrent' Processing Elem~iitl:
(PEs!, . . . .. ... . . . ,, , " " . .1,
Single.Instruction Multip\e Data · : Architecture in which 3: sing!~ instrµction is execut,e~ ip. parallel with. the}
(SIMD) Architecture help of the processing elements _.
MJMD Ai:chitrcture Ar~hitecture in .which ~he processing.eleme_nts execute different instruc-:,
tions at a given point of time · ·
Programming La,nguage An entity for capturing a 'Computational Model' and maps it into archi-
tecture
Data Flow Graph (DFG) Model : A data driven model in which the ,program execution is determined by
data
Control DFG (CDFG) Model A model containing both data operations and control operations. The CDFG
uses Data Flow Graph (DFG) as element and conditional (constructs) as
decision makers
State Machine Model : A model describing the system behaviour with 'States', 'Events', 'Actions'
and 'Transitions'
Statechart An entity for capturing the states, transitions, events an.d actions
Harel Statechart A type of statechart
Finite State Machine (FSM) Model A state machine model with finite number of states
Hierarchical/Concurrent Finite An extension of the FSM for supporting concurrency and hierarchy
State Machine Model (HCFSM)
Sequential Model Model for capturing sequential processing requirements
Concurrent or Communicating Model for capturing concurrently executing tasks/process requirements
Process Model ·
Object Oriented Model : Object based model for modelling system requirements
Unified Modelling Language (UML) : A visual modelling language for Object Oriented Design
UMLDiagram Diagram giving a pictorial representation of the static aspects, behavioural
aspects and organisation and management of different modules
 Introduction to Embedded Systems

. Objective Questions
1. Which of the following programming model is best suited for modelling a data driven embedded system
(a) State Machine (b) Data Flow Graph ,(c) Harel Statechart Model
(d) Noneoft}lese ,_
2. Which of the following programming model is best suited for modelling a Digital Signal Processing (DSP) embed-
ded system -
(a) Finite State Machine (b) Data Flow Graph (c) Object Oriented Model
(d) UML 1
3. Which of the following architecture is best suited for implementing a Digital Signal Processing (DSP) embedded
system
(a) Controller Architecture (b) CISC (c) Datapath Architecture (d) None of these
4. · Which of the following is a multiprocessor architecture?
(a) SIMD (b) MIMD (c) VLIW (d) All
(e) (a) and (b) (t) (b) and (c)
5. Which of the following model is best suited for modelling a reactive embedded system?
(a) Finite State Machine (FSM) (b) DFG (c) Control DFG
(d) Object Oriented Model
6. Which of the following models is best suited for modelling a reactive real time embedded system?
(a) Finite State Machine · (b) DFG (c) Control DFG
(d) Hierarchical/Concurrent Finite State Machine Model
7. Which of the following model is best suited for modelling an embedded system demanding multitasking capabili-
ties with data sharing?
(a) Finite State Machine (b) DFG (c) Control DFG
(d) Communicating Process Model
8. Which of the following is a hardware description language?
(a) C (b) System C (c) VHDL (d) C++
(e) (b) and (c)
 Hardware Software Co-Design and Program Modelling

9. Which of the following is a structural thing in UML?

(a) Class (b) Interaction (c) State Machine (d) Activity
(e) None of these
10. Which of the following is a behavioural thing in UML?
(a) Class (b) Interface (c) State Machine (d) Component
(e) None of these
11. Which of the following is not a static diagram in UML?
(a) Class Diagram (b) Object Diagram (c) Use case Diagram (d) Component Diagram
(e) None of these
12. Which of the following is not a behavioural diagram in UML?
(a) State Diagram (b) Object Diagram (c) Use case Diagram (d) Sequence Diagram
(e) None of these
13. Which of the following UML diagrams is best suited for Requirements Capturing?
(a) State Diagram (b) Use case Diagram (c) Object Diagram · (d) Seque_nce Diagram
(e) None of these
14. Which of the following UML diagram represents object interactions with respect to time?
(a) State Diagram (b) Sequence Diagram (c) Object Diagram (d) Use case Diagram
(e) None of these
15. Which of the following UML interaction diagram(s) emphasises oli structural organisation of objects?
(a) Collaboration Diagram (b) Sequence Diagram (c) State Diagram (d) Use case Diagram
(e) None of these
16. Which of the following is (are) trade-offs in hardware software partitioning?
(a) Processing speed (b) Memory requirement (c) Cost (d) All of these
(e) None of these

Review Questions
1. What is hardware software co-design? Explain the fundamental issues in hardware software co-design
2. Explain the difference between SIMD, MIMD and VLIWarchitecture
3. What is Computational model? Explain its role in hardware software co-design
4. Explain the different computational models in embedded system design
5. What is the difference between Data Flow Graph (DFG) and Control_" Data Flow Graph (CDFG) model? Explain
their significance in embedded system design
6. What is State and State Machine? Explain the role of State Machine in embedded system design
7. What is the difference between Finite State Machine Model (FSM) and Hierarchical/Concurrent Finite State
Machine Model (HCFSM)?
8. What is 'Statechart'? Explain its role in embedded system design
9. Explain the 'Sequential' Program model with an example
10. Expla1n the 'Concurrent/Communicating' program model. Explain its role in 'Real Time' system design
11. Explain the 'Object-Oriented' program model for embedded system design. Under which circumstances an Object-
Oriented model is considered as the best suited model for embedded system design?
12. Explain the role of programming languages in system design
13. What are the building blocks of UML? Explain in detail.
14. Explain the different types ofUML diagrams and their significance in each stage of the system development life
cycle
15. Explain the important hardware software 'trade-offs' in hardware software partitioning?
Introduction to Embedded Systems
r
i

Introduction to F;mbedded Systems

I hope by now you got a reasonably good knowledge on embedded systems, the different elements
of an embedded system, their application areas and domains, their characteristics and quality attributes.
Now it is time t9_ move on to the various steps involved in the design of embedded systems. As men-
tioned in Chapter 2 of the previous section, embedded systems are built around a central core which
can be a Commercial-off-the-Shelf Component (COTS) or an Application Specific Integrated Circuit/
Application Specific Standard Product (ASIC/ASSP) or a Programmable Logic Device (PLD) or a Gen-
eral Purpose Processor (Microprocessor/General Purpose Microcontrollers) or Application Specific In-
struction Set Processors (Special Purpose_Microcontrollers/Digital Signal Processors). Describing all of
them in detail is outside the scope of this book and for the time being we will be dealing with the design
of embedded systems using Application Specific Instruction Set Processor and the scope of this design
is again limited to designing with Microcontroller. The target microcontroller selected for the design ap-
proach is 8051 - Industry's most popular 8bit microcontroller. The architecture details of the basic 8051
controller and the instructions supported by it are already explained in some of the previous chapters.
In the next sections we will explore the possibilities of how the 8051 controller can be embedded into
different applications and how the 8051 can be programmed for various embedded applications.
The embedded product design starts with ,product requirements specification and analysis. When
a requirement arises for an embedded product, the requirements are listed out including the hardware
features required, the functionalities to be .supported, the product aesthetics (look 'n' feel) etc. On
finalising the requirements, the various hardware components and peripherals required to implement
the hardware features are identified and the interconnection among them are defined, the control algo-
rithm for controlling the various hardware and peripherals are developed, product aesthetics like look
and feel, enclosure unit, etc. are defined and the control algorithm is transformed to controller specific
instructions using the-firmware development tools and finally the hardware and fim1ware are integrated
together and the resulting product is tested for the required functionalities as per the requirement speci-
fications. The mechanical design of the-product takes care of the product aesthetics and develops a suit-
able enclosure for the product. Various standards like International Organisation for Standards (ISO)
and models like Capability Maturity Model (CMM), Process Capability Maturity Model (PCMM) etc.
are used in the entire design life cycle management. There will be well-defined documentation structure
(Templates) for the entire design life cycle. The Requirement Specification Document records the entire.
requirement for the product. Formal verifications of this document will be carried out before the system
design starts and it is termed as "Document Reviews". Once the requirement specifications are finalised
the preliminary design and detailed designs are carried out. The preliminary design and detailed design
deals with the different modules of the total system and what all hardware/firmware components are
required to build these modules, how these modules are interconnected and how they are controlled.
• The chapters in this section are organised in a way to give th1e readers the basic lessons on "Embed-
ded Hardware Design and Development", "Embedded Firmware Design and Development", "Integra-
tion and testing of the Embedded Hardware and Firmware", "Product Enclosure Development" and
Embedded Product Development Life Cycle Management". We will start the section with Embedded
Hardware Design and Development.
 Design and Development of Embedded Product
:i"
ts ! Integration testing
s.
1-
:h
tJ
1-
1-
)f

p-
i]
·s.
to

m
re
>n "'
nt i
-~
0-
)k '
t;
";)
'j
lC :1
!d -~l"
.,
:1- ',, u}

it-
))
:c.
re
re
m
ed
gn ....C
~
V,
'
A
C)

.re 1 r.;
C)
i..
OI
d- !
·a- ""Q
"'
C)

nd i..
OI
~
ed "C
i..
.........
OI
 ~ LEARNING OBJECTIVES
~,,L_..,....,-

✓ Learn about the various elements gf Embedded Hardwar~. and their design principl~~ . .• . , •·
✓ ~efresh ,kqqwledge on 'the bas~~}~g{oqE/eff:ron{c f9mpon1:nts and _circuits - Resistor, fopacitor, Diode,}n1~ttor, •.
Trans,isfdr etc..a!Jd their uje,.if ~[rifiedd,ea. appliccitigns .. · .. . . · ' , .. . .. , . . . .. . , ,., !.)f". '
7

✓ Refresh knowledge on the 'basiG}Q,it,al Electronie.componenH gryd :arc1/its Logic 'Gates,' ~uffer ICs, Latc/1 l~f~g,}
coder ahdfnco8er ICs, Multiplexer{MllX) ·and De-multiplexer (D-MUXYCombinationdl and Sequentfal.Cirqli~Jfrr:J .
their use in embedded applic~tfons· .· .. . . . . .· •.· . . { , . . . . < -· . ·, • • . •. . ; , ' \ ';

v Learn. abqut In{egrated .tirc.uits (!Cs), Jhe}Je~ree o[in,tegrgtiof{ itJ. vqrious types· i;Jf In'tegrated Circu7ts; 1n}tlog,
Digital an(! MixedSig(1a{Jntfigrgteq,Circufts/t~eJte11,sjnY,~lied in'f(J)esigny . ' . .. , '>,
✓ Learn abbut Electronic PesigiJ Aytomation to~l/fo.r Ergbedded Hardware D~sigrj and EDA tools for Printetf Cir4qit
Board Design . .•. . .. · . . . ·. . . . · · y

✓ Famaiarise ,witb}he usage 0Jtry~pcca4 ED,t.too{Jromfadenr:esofttyqie forPrinted :Circuit Board Design .·· .
✓ Familiah'se. with 'the differer;,f efltfties for circuft.rlfr;igram. de.sigh (schemrittc design) using.• the Dread Cap(ureCIS
tool. Familiq,rise.with the diff~rententftigs oftbe Cqpt1re GIS toij(:tw~. 'Drqi,ying Canvas', 'Drawing Tool', .'Dr~wfug
Details', iart Number creation', :,Design Rule check (DRC)', 'Bill oj Maten.al (BdM)' creation, 'Netli'st file creation for
PCB blueprint design, etc.
✓ Familiarise with the usage of 'Layout' tool from Cadence for generating the PCB design files from the circuit diagram
description file (From Netlist file) ·
✓ Learn the building blocks of 'PCB Layout' - Footprints (Component Packages), Routes/Traces, Layers, Via, Marking
text and graphics, etc.
✓ Learn about Board Outline creation, Component placement, Layer selection, PCB Track Routing, Assembly note cre-
ation, Text and graphics addition, PCB Mounting hole creation, Design Rule Checking, Gerber file creation, etc. using
Layout tool
✓ Learn the important guidelines for a good PCB design
✓ Learn about the different mechanisms for PCB fabrication, different types of PCBs, How a finished PCB looks like and
how it is made operational
 Embedded Hardware Design and Development

As mentioned at the beginning of this book, an embedded system is a combination of _special purpose
hardware and software (firmware). The hardware of embedded system is built around analog electronic
components and circuits, digital electronic components and circuits, and integrated circuits (ICs). A
printed circuit board (PCB) provides a platform for placing all the necessary hardware components for
building an embedded product, like a chess board where you can move the pawns, rookies and bishop.
If you are building a simple hardware or a test product, you can use a bread-board to interconnect the
various components. For a commercial product you cannot go for a -bread-board as an interconnec-
tion platform since they make your product bulky and the breadboard connections are highly unstable
at:).d your product may require thousands of inter connections. Printed circuit boards (PCB) act as the
. ba.ckbone of embedded hardware. This chapter is organised in such a way to refresh the reader's knowl-
edge on various analog and digital electronic components and circuits, familiarise them with Integrated
Circuit designing and provide them the fundamentals of printed circuit boards, its design and develop-
ment using electronic design automation (EDA) tools. ·

Resistors, capacitors, diodes, inductors, operational amplifiers (OpAnips ), transistors, etc. are the com-
monly used analog electronic components in embedded hardware design. A resistor limits the current
flowing through a circuit. Interfacing of LEDs, buzzer, etc. with the port pins of microcontroller through
current limiting resistors is a typical example for the usage of resistors in embedded application. Ca-
pacitors and inductors are used in signal filtering and resonating circuits. Reset circuit implementation,
matching circuits for RF designs, power supply decoupling, etc. are examples for the usage of capacitors
in embedded hardware circuit. Electrolytic capacitors, ceramic capacitors, tantalum capacitors, etc. are
the commonly used capacitors in embedded hardware design. Inductors are-widely used for filtering the
power supply from ripples and noise signals. Inductors with inductance value in the microhenry (µH)
range are commonly used in embedded applications for filter and matching circuit implementation.
P-N Junction diode, Schottky diode, Zener diode, etc. are the commonly used diodes in embedded
hardware circuits. A schottky diode is same as a P-N junction diode except that its forward voltage
drop (voltage drop across diode when conducting) is very low (of the order of 0.1 SV to 0.45) when
compared to ordinary P-N junction diode (of the-ord.er of 0.7V to 1.7V). Also the current switching
time of schottky diode is very small compared to the ordinary P-N junction diode. A zener diode acts
as normal P-N junction diode when forward biased. It also permits current flow in the reverse direction,
if the voltage is greater than the junction breakdown voltage. It is normally used for voltage clamping
applications. Reverse polarity protection, voltage rectification (AC-DC converters), freewheeling of
current produced in inductive circuits, clamping of voltages to a desired level (e.g., Brown-out protec-
tion circuit implementation using zener diode), etc. are examples for the usage of diodes in embedded
applications.
Transistors in embedded applications are used for either switching or amplification purpose. In
switching application, the transistor is in either ON or OFF state. In amplification operation, the transis-
toris always in the ON state (partially ON). The current is below saturation current value and the current
through the transistor is variable. The common emitter configuration of NPN transistor is widely used
in switching and driving circuits in embedded applications. Relay, buzzer and stepper motor driving
circuits are examples for common emitter configuration based driver circuit implementation using tran-
sistor (Please refer to Chapter 2).
 Introduction to Embedded Systems

Digital electronics deal with digital or discrete signals. Microprocessors, microcontrollers and system
on chips (SoCs) work on digital principles. They interact with the rest of the world through digital I/O
interfaces and process digital data. Embedded systems employ various digital electronic circuits for
'Glue logic' implementation. 'Glue logic' is the custom digital electronic circuitry required to achieve
compatible interface between two different integrated circuit chips. Address decoders, latches; encod-
ers/decoders, etc. are examples for glue logic circuits. Transistor Transistor Logic (TTL), Complemen-
tary Metal Oxide Semiconductor (CMOS) logic etc are some of the standards describing the electrical
characteristics of digital signals in a digital system. The following sections give an overview of the
various digital I/O interface standards and the digital circuits/components used in embedded system
development.

8.2.l Open Collector and Tri-State Output

Open collector is an I/O interface standard in digital system design. The term 'open collector' is com-
monly used in conjunction with the output of an Integrated Circuit (IC) chip. It facilitates the interfacing
of IC output to other systems which operate at different voltage levels. In the open collector configura-
tion, the output line from an IC circuit is connected to the base of an NPN transistor. The collector of
the transistor is left unconnected. (floating) and the emitter is internally connected to the ground signal
of IC. Figure 8.1 illustrates an open collector output configuration.

Vee

IC internal circuitry <l)

0 Pull-up
<f:l resistor
I
..... 0/p pin
I
I
i~
I
I
I
( Fig. 8.l J Open copec:tor output c:oniiguriJ.tion.

For the output pin to function properly, the output pin should be pulled, to the desired voltage for
the o/p device, through a pull-up resistor. The output signal of the IC is fed to the base of an open col-
lector transistor. When the base drive to the transistor is ON and the collector is in open state, the o/p
pin floats. This state is also known as 'high impedance' state. Here the output is neither driven to logic
'high' nor logic 'low'. If a pull-up resistor is connected to the o/p pin, when the base drive is ON, the o/p
pin becomes at logic 0 (0V). With a pull-up resistor, if the base driver is 0, the o/p will be at logic high
(Voltage = Vcc). The advantage of open collector output in embedded system design is listed below.
1. It facilitates the interfacing of devices, operating at a voltage different from the IC, with the IC.
Thereby, it eliminates the need for additional interface circuits for connecting devices at different
voltage levels.
 Embedded Hardware Design and Development

2. An open collector configuration supports multi-drop connection, i.e., connecting more than one
open collector output to a single line. It is a common requirement in modem embedded systems
supporting communication interfaces like I2C, 1-Wire, etc. Please refer to the various interfaces
described in Chapter 2 under the section 'Onbo~niCommunication Interfaces'.
3. It is easy to build 'Wired AND' and 'Wired OR'-configuration using open collector output lines.
The output of a standard logic device has two states, namely 'Logic O(LOW)' and 'Logic 1 (HIGH),
and the output will be at any one of these states at a given point of time, whereas tri-state devices have
three states for the output, namely, 'Logic O(LOW)', 'Logic 1 (HIGH) and 'High Impedance (FLOAT)' .
. A tri-state logic device contains a device activation line called 'Device Enable'. When the 'Device En-
able' line is activated (set at 'Logic l' for an active 'HIGH' enable input and at 'Logic O' for an active
'LOW' enable input), the device acts like a norinal logic device and the output will be in any one of the
logic conditions, 'Logic O(LOW)' or 'Logic 1 (HIGH)'. When the 'Device Enable' line is de-activated
(set at 'Logic O' for an active 'HIGH' enable input and at 'Logic l' for an active 'LOW' enable input),
the output of the logic device enters in a high impedance state and the device is said to be in the floating
state. The tri-stated output condition produces the effect of 'removing' the device from a circuit and al-
lows more than one devices to share a common bus. With multiple 'tri-stated' devices share a common
bus, only one 'device' is allowed to drive the bus (drive the bus to either 'Logic O' or 'Logic l ') at any
given point of time and rest of the devices should be in the 'tri-stated' condition.

8.2.2 Logic Gates

Logic gates are the building blocks of digital circuits. Logic gates control the flow of digital information
by performing a logical operation of the input signals. ·Depending on the logical operation, the logic
gates used in digital design are classified into-AND, OR, XOR, NOT, NAND, NOR and XNOR. The
logical relationship between the output signal and the input signals for a logic gate is represented using
a tmth table. Figure 8.2 illustrates the tmth table and symbolic representation of each logic gate.

8.2.3 Buffer
A buffer circuit is a logic circuit for amplifying the current or power. It increases the driving capability
of a logic circuit. A tri-state buffer is a buffer with Output Enable control. When the Output Enable con-
trol is active (Low for Active low enable and High for Active high enable), the tri-state buffer functions
as a buffer. If the Output Enable is not active, the output of the buffer remains at high impedance state
(Tri-stated). Tri-state buffers are commonly used as drivers for address bus and to select the required
device among multiple.devices connected to a shared data bus. Tri-state buffers are available as either
unidirectional or bi-directional buffers. 74LS244/74HC244 is an example of unidirectional octal buffer.
It contains 8 individual buffers which are grouped into two. Each buffer group has its own output enable
line. Figure 8.3 illustrates the 74LS244 buffer device.
IC 74LS245 is an example of bi-directional tri-state buffer. It allows data flow in both directions, one
at a time. The data flow direction can be set by the direction conttol line. One buffer is allocated for the
data line associated with each direction. Figure 8.4 illustrates the 74LS245 octal bi--directional buffer.

8.2.4 Latch
A latch is used for storing binary data. It contains an input data line, clock or gating control line for trig-
gering the latching operation and an output line. The gating signal can be either a positive edge (raising
,1
JI
\ Introduction to Embedded Systems
l

AND Gate-Truth Table NANO Gate -Truth Table

0
0
0
1
0
0
.I1==[)2-
I2
0
0
0
1
1
1
I1=[)2
l2
1
1
0
l
0
1
1
1
0
1
l
0
./
OR Gate -Truth Table NOR Gate -Truth Table

0 0 0 0 1
0 1 1 !1~ 0 1 0 !1~
-I2 . 12
1 0 l 1 0 0
1 1 1 ·1 0

NOT Gate -Truth Table XOR Gate-Truth Table

0 0 0
0 1 0 1 1
I~
1 0 l 0 1
1 1 0

XNOR Gate -Truth Table

0 0 l
0 1 0 11~
12
1 0 0
1 1 1

edge) or a negative edge (falling edge). Whenever a latch trigger happens, the data present on the input
line is latched. The latched data is available on the output line of the latch until the next trigger. D flip
flop is a typical example of a latch (refer to your Digital Electronics course material-there exist differ-
ent types of latches namely S-R, J-K, D, T, etc.). In electronic circuits, latches a:re commonly used for
latching data, which is available only for a short duration. Atypical example is the lower order address
information in a multiplexed address-data bus system. Latches are available as integrated cin:::uits, IC
74LS373 being a typical example. It contains 8 individual D latches. '
The 74LS373 latch IC is commonly used for latching the lower order address byte in a multiplexed
address data bus system. The address latch enable (ALE) pulse generated by the processor,· when the
address bits are available on the multiplexed bus, is used as the latch trigger. Figure 8.6 illustrates the
usage of latches in address latching.
 Embedded Hardware Design and Development

74LS373
Do Oo
Al Bl D Q\
A2 B2
A3 B3
A4 B4
A5 BS
A6 B6
A7 B7
A8 B8

DIR E\
Latch Enable Output
(LE) Enable (OE\)

Multiplexed Address Data Bus

- ..... - - - - - - - · D0 ....D7

AO ....A7

1t
p
r-
>r
;s 8.2.5 Decoder
C Adecoder is a logic circuit which generates all the possible combinations of the input signals. Decoders
are named with their input line numbers and the possible combinations of the input as output. Examples
d are 2 to 4 decoder, 3 to 8 decoder and 4 to 16 decoder. The 3 to 8 decoder contains 3 input signal lines
·. and it is possible to have 8 different configurations with the 3 lines (000 to 111 in the input line cor-
:respo~ds to Oto 7 in the output line). Dep~;iding on the input signal, the corresponding output line is
asserted. For example, for the input state OJ)l, .the output line 2 is asserted. Decoders are main1y used for
address decoding and chip select sigdl'getteration in electronic circuits and are available as integrated
circuits. 74LS138/74AHC138 is an example for 3to 8 decoder IC. Figure 8.7 illustrates the 74AHCf38
, decoder and the function table for it. · '.'
 Introduction to Embedded Systems

74AHC138 Input Output !

Oo\
A2 A1 Ao E1\ ~\
E,\ Oo\ 01\ 02\ 0,\ 1
04\ Os\ O,;\ 01\:
01\
0 0 0 0 0 1 0 1 1 1 1 1 1 1
Ao, 02\ 0 0 1
03\
i
0 0 1 1 0 1 1 1 1 1 ] i
A1
0 1 0 0 0 1 1 1 0 1 1 1 1 1
A2 04\ I

0 0 1 1 1 1 0 1 1 1 1
)--or
05\ 0
1
1
0
1
0 0,0 1 1 1 1 1 0 1 1
i
i

i 1
07\ 1 1 1 1 1 1 I
1 0 1 0 0 1 1 0 i
i
I
1 1 0 010 1 \1 1 1 1 1 1 0 1
er,
~
,.,.. 1 1 1 0 0 i 1 1 1 1 1 1 1: 0
w w w"'

The decoder output is enabled only when the 'Output Enable' signal lines El\, E2\ and E3 are at logic
levels 0, 0 and 1 respectively. If the output-enable signals are not at the required logic state, all the output
lines are forced to the inactive (High) state. The output line corresponding to the input state is asserted
'Low' when the 'Output Enable' signal lines are at the required logic state (Here El \=E2\=0 and E3 =1).
The output line can be directly connected to the chip select pin of a device, if the chip select logic of the
device is active low.

8.2.6 ·Encoder
An encoder performs the reverse operation of decoder. The encoder encodes the corresponding input
state to a particular output format. The binary encoder encodes the input to the corresponding binary
format. Encoders are named with their input line numbers and the encoder output format. Examples are
4 to 2 encoder, 8 to 3 encoder and 16 to 4 encoder. The 8 to 3 encoder contains 8 input signal lines and it
is possible to generate a 3 bit binary output corresponding to the input (e.g. inputs 0 to 7 are encoded to
binary 111 to 000 in the output lines). The corresponding output line is asserted in accordance with the
input signals. For example, if the input line 1 is asserted, the output lines AO, Al andA2 are asserted as
0, 1 and 1 respectively. Encoder:s are mainly used for address decoding and chip select signal generation
in electronic circuits and are available as integrated circuits. 74Fl 48/74LS 148 is an example of 8 to 3
encoder IC. Figure 8.8 illustrates the 74Fl48/74LS 148 encoder and the function table for it.
The encoder output is enabled only when the 'Enable Input (EI)' signal line is at logic 0. A 'High' on
the Enable Input (EI) forces all outputs to the inactive (High) state and allows new data to settle without
producing erroneous information at the outputs. The group signal (GS) is active-Low when any input is
Low: this indicates when any input is active. The Enable Output (EO) is active-Low when all inputs are
at logic 'High'. 74LS148/74Fl48 is a priority encoder and it provides priority encoding of the inputs to
ensure that only the highest order data line is encoded when multiple data lines are asserted (e.g., when
.both input lines 1 and 6 are asserted, only 6 is encoded and the output will be 001. It should be noted that
the encoded output·is an inverted value/if the corresponding binary ·data. (e.g., the output lines A2, Al
and AO will be at logic levels 000 when the input 7 is asserted). Encoding of keypress in a keyboard is
a typical example for an application requiring encoder. The encoder converts each keypressto a binary
code·.
 Embedded Hardware Design and Development

74I.S148
o.
1
2 AO 1 0 1
3 Al 1 1 .1 1 1 0 1. ~ 1 1) 0 l 0
4 A2
5 1 1 1 1 0 1 1 1 0 0 1 1 0
6 1 1 1 0 1 -1 1 l· 0 0 1 0 1
7 1 1 0 1 1 I 1 1 0 0 I 0 1 0 !

1 0 1 1 1 1 I I 0 0 1 0 0 i I
0
~ -
---d00 ---~ 0 I I I 1 1 l 1 0 0 1 0 0 0

8.2.7 Multiplexer (MU.X:)

A multiplexer (MUX) can be considered as a digital switch which connects one input line from a set of
input lines, to an output line at a given point of time. It contains multiple input lines and a single output
line. The inputs of a MUX are said to be multiplexed. It is possible to connect one input with the output
line at a time. the input line.is selected through the MUX control lin~s. 74S151 is an example for 8 to 1
) multiplexer IC. Figure 8.9 illustrates the 74S151 multiplexer and the function table for it.

y
IXl 74LS151
D1
D2 Y\
1
0
1 1 0
I 0 0 0 D4 D4\ i
1 0 1 0 D5 D5\
1 1 0 0 D6 D6\
I 1 1 0 D7 D7\
ffi X X X1 0 ]
Channel Select x: Don't care

The multiplexer is enabled only when the 'Enable signal (EN)' line is at logic 0. A 'High' on the EN
line forces the output to the inactive (Low) state. The input signal is switched to the output line through
,the ~hannel select control lines A2, Al and AO. In order to select a particular input line, apply its binary
equivalent to the channel select lines AO, Al and A2 (e.g. set A2AIAO as 000 for selecting Input DO,
and as 001 for selecting channel DI, etc.).
 Introduction to Embedded Systems

8.2.8 De-multiplexer (D-MUX)

A de-multiplexer performs the reverse operation of multiplexer. De-multiplexer switches the input sig-
nal to the selected output line among a number of outputlines. The output line to which the input is to be
switched is selected by the output selector control lines. The 1 to 2 de-multiplexer, NL7SZ 18 is a typical
example for 1 to 2 de-multiplexer IC. It contains a single input line and two output lines to switch the
input line. The output switching is contrqlled by the output selector control. Figure 8.10 iHustrates ·the
NL7SZ18 de-multiplexer and the function table for it.

NL7SZ18
I YO

s
Output.
Selector I Yl
'----------' Z : High Impedance

When one output line is selected by the output selector control (S), the other output line remains in the
High impedance state.

8.2.9 Combinational Circ;uits

In digital system design, a combinational circuit is a combination of the logic gates. The output of the
combinational circuit, at a given point of time, is dependent only on the state of the inputs at the given
point of time. Encoders, decoders, multiplexers, de-multiplexers, adder circuits, comparators, multiple
input gates, etc. are examples of digital combinational circuits. The design requirements for a combi-
national circuit are expressed as 'A set of statements' or 'Truth Table' or 'Boolean Expressions'. The
combinational circuit can be implemented either by simplifying the Boolean expression/Truth table apd
realising the simplified expression using logic gates or by directly implementing the lo'gic expressions
using an 'Off-the-shelf' Medium Scale Integrated Circuit Chip. Various logic simplification techniques
like 'Kamaugh Map (K Map)', 'Algebraic method', 'Variable Entered Mapping (VEP)' and 'Quine-Mc-
Cluskey method,' etc. are used for the simplification oflogic expressiqns.
In digital system design, logical functions representing a combinational circuit are expressed as ei-
ther 'Sum of Products (SOP)' or 'Product of Sums (POS)' form. The SOP fonn represents the logic as
the sum of the products of the logical variables whereas the POS form represents the logic as the product
of sums of the logical variable.
The expression Y =AB+ BC+ AC is an example for SOP form representation of the logical function.
Here Y is the output signal and A, B and C are the input signals. .
The e~pression Y (A+B) (B+C) (A+C) is an example forPOS fonn representation of thJ\logical
function. Here Y is the output signal and J, f1-tand Care the input signals. . \
'~amaugh map' or K-map is the easiest.log~c sim~li~~a!io~ technique f~r arriv~n~ at the logi~ ex-
1

pression when the 'Truth Table' of the co111bmational circmt is given. Depending on the m,rnbqr of mput
signal variables, K-maps are named as 2-variable, 3-variable, 4-variable, etc . K-map 'is the most suitable
 Embedded Hardware Design and Development

candidate for handling input variables up to 6. Now let us try to implement a 2 input half adder combi-
national circuit, for adding two one-bit numbers, using the K-map technique. The 'Truth Table' and the
g- corresponding K-map drawingt for the 2 input 'half adder' circuit is given below.
be
:al 0 1 0
A A 1
he B B
he
0 0 0 0 0 0 0 0
0 1 1 0
1 0 1 0 0 1
1 1
1 1 0 1
C: Carry K-Map for Output (0) K-Map for Carry (C)
0Rlg:j3~ f l1 ).Tr~tii Tab~e,'##ciK,rnap
-> ,. • ,::,;,, ·. ·i~~~~:~i.n:tati&zi.t:
·.. ·/ '-,
~-·--- ,,, ·· ·, -') ,_:_,.",;;,;_,,. ,,, · ;~•-·0·'··": ,:;:·:__;,<<·
!>~Hittiaa~r.;
0 ,->..-,.,.'.·:}'>' ·,, "''-······· -:.:- ,·',;,f'!'-::'" . . :-··~;;·.:r'Sf".t\,":(•:

The simplified logical expression for the output (Y) and carry (C) of half adder is given below.
Y=AB+AB
C=AB
The logical expression AB+ AB represents an X.OR gate. Please refer to the 'truth table' of XOR gate
:he gh'.en under the 'Logic Gates' section. Using K-map it can be represented as:

XOR Gate - Truth Table A 0 1

B
the 0 0 0 0 0 1
'en
0 1 1
ple 1 1 0
1 0 1
bi-
'he 1 1 0 K-Map for XOR Gate
md
ms
(fi<j~Kl2) TruthTable andK-map representation for~ORGaJe

1es
Hence, the half adder circuit can be realised using an XOR _A_____~ ~ = A \ B + A &
1c-
and an AND gate. The circuit implementation is shown in _B___- - + - - ~ ~
Fig. 8.13.
e1-
as
8.2.10 Sequential Circuits
uct

on.
Digital logic circuit, whose output at any given point of --- C=AB

time depends on both the present and past inputs, is known

as. sequential circuits. Hence, sequen.tial circuits contain a (Fig.B.13) ;~~~j~P:~~ C:itt:uit
.cal .Iiflpi~~eiltli'.{ion .
memory element for holding the previous input states. In
general, a sequential circuit can be visuali,sed as a combinational circuit with memory elements.
ex-
put
.ble t Please refer the book 'Modern Digital Electronics by RP Jain' for more details on the K-map drawing and simplification methods.
 Introduction to Embedded Systems

Flip-flops act as the basic building blocks of sequential cir- - Combinational

cuits. Sequential circuits are of two types, namely-synchronous Inputs Circuit
(clocked) sequential circuits and asynchronous sequential circuits.
The operation of a synchronous sequential circuit is synchronised Memory
to a clock signal, whereas an asynchronous sequential circuit does Elements
not require a clock for operation. For an asynchronous sequential
circuit, the response depends upon the sequence in which the input
signal changes. The memory capability to asynchronous sequential
circuit is provided through feedback. Register, synchronous coun-
ters, etc. are examples of synchronous serial circuits, whereas ripple or asynchronous counter is an
example for asynchronous seqt1ential circuits.
Now let us have a look at.how a flip-flop circuit acts as a memory storage element. The name flip-flop
is conveying its intended purpose. It tumbles the output based on the input and other controlling signals.
As a starting point on the discussion of flip-flops, let us talk about Set Reset (S-R) flip-flop. The logic
circuit and the 1/0 states for an S-R flip-flop are given in Fig. 8.15.

s
Q\
0 0 0 0
0 0 1 l
0 l 0 0
0 1 1 0
R Q 1 0 0 1
1 0 1 1
1 1 0 X
1 1 1 X

The S-R flip-flop is built using 2 NOR gates. The output of each NOR gate is fed back as input to the
other NOR gate. This ensures that if the output of one NOR gate is at logic 1, the output of the other
NOR gate will be at logic 0. The.S-R flip-flop works in the following way.
1. If the Set input (S) is at logic high and Reset input (R) is at logic low, the output remains at logic
high regardless of the previous output state.
2. If the Set input (S) is at logic low and Reset input (R) is at logic high, the output remains at logic
low regardless of the previous output state.
• 3. If both the Set input (S) and Reset input (R) are at logic low, the output remains at the previous
logic state.
4. The condition Set input (S) Resetinput (R) = Logic high (1) will lead to race condition and the
state of the circuit becomes undefined or indeterminate (x).
A clock signal can be used for triggering the ,state change of flip-:flops. The clock signal can be either
level triggered or edge triggered. For level triggered flip-flops, the output responds to any changes in
input signal, if the clock signal is active (i.e., if the clock signal i$ at logic 1 for 'HIGH'.level triggered
and at logic O for 'LOW' level triggered clock signal). For edge triggered flip-flops, the output state
changes only when a clock trigger happens regardless of the changes in the input signal state. The clock
trigger signal can be either a positive edge (AO to 1 transition) or a negative edge (A 1 to Otransition).
Figure SJ~ illustrates the implementation of an edge triggered S-Rflip-flop.
 Embedded Hardware Design and Development

The clocked S-R flip-flop functions in the same way as s

that of S-R flip-flop. The only difference is that the out- - - - - - 1
put state changes only with a clock trigger. Even though
there is a change in the inputstate, the output remains un-
changed until the next clock trigger. When a clock trigger C
occurs, the output state changes in accordance with the
values of Sand R at the time of the clock trigger. R
We have seen that the input condition S=R= 1 is unde- - - - - - 1
fined in an S-R flip-flop. The J-K flip-flop augments the
behavior of S-R flip by interpreting the input state S=R= 1
as a toggle conimand. The logic circuit and the I/0 states for a J-K flip-flop are given in Fig. 8.17.

J
s Q
0 0 0 0
0 0 1 . 1
CL
S-R Flip-
0 1 0 0
K Flop 0 1 1 0
R Q\
1 0 0 1
I . 0 1 l
1 1 0 l
l 1 l 0

From the circuit implementation, it is clear that for a J-K flip-flop, S =JQ\ and R = KQ. The J-K flip-flop
operates in the following way:
1. When J = I and K = 0, the output remains in the set state.
2. When J = 0 and K I, the output remains in the reset state.
he 3. When J =K 0, the output remains at the previous logic state.
ter 4. When J = I and K = I, the output toggles its state.
AD-type (Delay) flip-flop is formed by connecting a NOT gate in between the Sand R inputs of anS-R
flip-flop or by connecting a NOT gate between the J and K inputs of a J-K flip-flop. Figure 8.18 illus-
trates a D-type flip-flop and its I/0 states.

Q
,us
J-KFlip-
:he Flop
Q\ 1 1

1er
m
·ed
:1.te This flip-flop is known with the so-called name 'Delay' flip-flop for ~he following reason-the input to
,ck the flip-flop appears at the output at the end of the clock pulse (for faliing1edge triggering).
n). . A Toggle flip-flop or T flip-flop is formed by combining the J and K inputs of a J-K flip-flop. Figure
8.19 illustrates a Tfiip-flop and its I/0 states.
 Introduction to Embedded Systems

J Q

CL J-KFlip- Qni-1 : Present Output

Flop Qn : Previous Output
K Q\

When the 'T' input is held at logic 1, the T flip-flop toggles the output
with each clock signal. An S-R flip-flop cannot be converted to a 'T' Q
flip-flop by combining the inputs S and R. The logic state S=R= I is s
not defined in the S-R flip-flop. However, an S-R flip-flop can be con- CL S-R Flip-
figured for toggling the output with the circuit configuration shown- in Flop
Fig. 8.20. R Q\
The synchronous sequential circuit uses clocked flip-flops (S-R, J-
K, D, T etc.) as memory elements and a 'state' change occurs only in
response to a synchronising clock signal. The clock signal is common
to all flip-flops and the clock pulse is applied simultaneously to all flip-
flops. As an illustrative example for synchronous sequential circuit, let
I
us consider the design of a synchronous 3-bit binary counter.
The counting sequence for a 3-bit binary counter iJ given below.

From the count sequence, it is clear that the LS bit (Q 0) of the binary counter toggles on each count and
the next LS bit (QI) toggles only when the LS bit (Q 0) makes a transition from 1 to 0. The Bit (Q2) of
the binary counter toggles its state only when the Q1 bit and Q0 bits are at logic 1. This logic circuit can
be realised with 3 T flip-flops satisfying the following criteria:
1. All the T flip-flops are driven simultaneously by a single clock (synchronous design).
2. The output of the Tflip-flop representing the Q0 bit is initially set at 0. The_input line of Q0 flip-flop
is connected to logic l to ensure toggling of the output with input clock signal.
3. Since Q1 bit changes only when Q0 makes a transition from 1 to 0, the output of the T flip-flop
representing Q0 is fed as input to the T flip-flop representing the Q1 bit.
4. The output bit Q2 changes only when Q0 =QI= 1. Hence the input to the flip-flop representing bit
Q2 is fed by logically ANDing Q0 and Q1.
 Embedded Hardware Design and Development

The circuit realisation of 3-bit binary counter using 3 T flip-flops is given in Fig. 8.21.

Qo Q1 Q2

Preset Logic
.~
Preset Preset Preset
Logic 1T Qo T Q1 T ~
Q2
Sl ?
T Flip- CL t> T Flip-
rC
!
CL T Flip-
">

Pul se to Flop Flop ·Flop

Co unt
i
11
' Clear Clear ; Clear
Clear Logic

The Preset line is used for setting the output of flip-flop, whereas the Clear line is used for resetting
the output of flip-flops. The counter changes in accordance with the count pulses.
Another example for synchronous sequential circuit is 'register'. A register can be considered as a
group of bits holding information. A D flip-flop can be used for holding a 'bit' information. An 8 bit
wide register can be visualised as the combination of 8 D flip-flops. T-h{} bit storing operation is con-
trolled by the signal associated with a latch write (like a write to latch pulse). The figure given below
illustrates the implementation of a 4 bit register using D flip-flops.

Q3 Q2 Q1 Qo

Preset Lcgic
I

Preset Presu Preset Preset

D D
,-- ...._
-D ~
'·-
D f---

fl D Flip- Cl
rC
D Flip-
>· Flop
Cl I', D Flip-
- __,..
CI
'-?
D Flip-
Cb(k Flop Flop Flop.
!
!
i
' Clear Clear Clear ' Clear
Cl! a Lcgic
!

D3 D2 D1 Do
 Introduction to Embedded Systems

The state of an asynchronous sequential circuit changes instantaneously with changes in input signal
state. The asynchronous sequential circuit doesnot require a synchronising clock signal for its operation.
The memory element of an asynchronous sequential circuit can be either an un-clocked flip-flop or logi-
cal gate circuits with feedback loops for latching the state. As an illustrative example, let us explore how
we can implement the above 3-bit binary counter using an asynchronous sequential circuit. From the
count sequence of the 3-bit binary counter, it is clear that the least significant (LS) bit (Q0) .of the binary
counter toggles on each count and the next LS bit (Q 1) toggles only when the LS bit (Q 0) makes a-transi-
tion from 1 to 0. The most significant (MS) Bit (Q2) of the binary counter toggles its state only when
the Q1 bit makes a transition from 1 to 0. This logic circuit can be realised with 3 T flip-fl.op~ satisfying
the following criteria:
1. The T input of all flip-flops are connected to logic high (it is essential for the toggling condition,'
of the T Flip-fl.op). '
2. The pulse for ~ounting is applied to the clock input of the first T flip-flop representing the LS bi(
Qo· ..
3. The clock to the T flip-fl.op representing bit Q1 is supplied by the output of the T flip-flop repre-
senting bit Q0. This ensures that the output of Q1 toggles only when the output of Q0 transitions
from 1 to 0.
4. The clock to the T flip-flop representing bit Q2 is supplied by the output of the T flip-flop repre-
senting bit Q1• This ensures that the output of Q2 toggles only when the output of Q1 transitions
from 1 to 0.
The circuit realisation of the 3-bit binary counterusing 3 T flip-flops in an asynchronous sequential
circuit is given below.

Qo' Q1 Q2
Logic 1

Preset Logic
Preset Preset Preset
T Qo T Q1 T Q2

IL T Flip- CL T Flip- CL TJ[_lip-

Pulse to Flop Flop Flop
Count

Clear Clear . Clear

Clear Logic

( Fig. 8,23) 3-Bit Binary Coµnter Implementation using T J1ip.,.Ffop

The Preset line is used for setting the output.of flip-flop, whereas the Clear line is used for resetting
the output of flip-flops. Here the input line (T) of all flip-flops is tied to logic 1 pennanently. Hence, the
clock signal to each flip-flop can be treated as the inputto the flip-fl.op, instead of treating it as a clock
pulse.
The table given below summarises the characteristics, pros and cons of synchronous and asynchro-
nous sequential circuits.
 Embedded Hardware Design and Development

· The output state of asynchronous circuit changes instantaneously with input signals; hence the speed
·. of operation of asynchronous sequential circuits is high compared to that of synchronous sequential cir-
c1:1its. Asynchronous _sequential circuits are preferred over synchronous sequential circuits for applica-
tions requiring high speeds and applications in which the input state change can happen asynchronously.
Asynch:ronous sequential circuits are cheaper to develop, compared to synchronous sequential circuits.

In the beginning of the electronics revolution we started building electronic circuits around the early
vacuum tube technologies. As technology progressed, transistors came into the picture and we shifted
our circuit designs to transistor based technology. In·the ancient times thousands of individual transis-
tors were required to build a digital or ~nalog functionality. The transistors were interconnected us-
ing conductive wires for building the required functionality. As technology gained new dimensions,
the concept of miniaturisation evolved and researchers and designers were able to build the required
functionality within a single silicon wafer, in places of thousands of interconnected transistors. An inte-
gr-ated circuit (IC) is a miniaturised form of an electronic circuit containing transistors and other passive
electronic components. In an IC, the circuits, required for building the functionality (say Processing
logic: CPU), are built on the surface of a thin silicon wafer. The first integrated circuit was designed
in the 1950s. Depending on the number of integrated components, the degree of integration within an
integrated circuit (IC) is known as:
Small-Scale Integration (SSI): Integrates one or two logic gate(s) per IC, e.g. LS7400
Medium-Scale Integration (MSI): Integrates up to 100 logic gates in an IC. The decade Counter 7490
is an example for MSI device
Large-Scale Integration (LSI): Integrates more than 1000 logic gates in an IC
Very Large-Scale Integration (VLSI): Integrates millions of logic gates in an IC. Pentium processor
is an example of a VLSI Device.
The IC design methodology has evolved over the years from the first generation design, SSI to de-
signs with millions of logic gates. The gate count is a measure of the complexity of the IC. In today's
world almost all IC designs fall under the category VLSI and it is a common practice to term IC design
as VLSI design. Depending on the type of circuits integrated in the IC, the IC design is categorised as:
Digital Design: Deals with the design of integrated circuits handling digital signals and data. The
I/O requirement for such an IC is always digital. Microprocessor/rnicrocontroller, memory, etc. are
examples of digital design.
 Introduction to Embedded Systems

Analog Design: Deals with the design of integrated circuits handling analog signals and data. Analog
design gives more emphasis to the physics aspects of semiconductor devices such as gain, power dis-
sipation, resistance, etc. RF IC design, Op-Amp design, voltage regulator IC design, etc. are examples
for Analog IC Design.
Mixed Signal Design: In today's world, most of the applications require the co-existence of digital
signals and analog signals for functioning. Mixed signal design involves design of ICs, which handle
both digital and analog signals as well as data. Design of an analog-to-digital converter is an example
for mixed signal IC design.
Integrated circuit design or VLSI ·design involves a number of steps namely, system specification,
functional or architectural design, functional simulation, logic synthesis, physical layout (placement
and routing) and timing simulation. As in the case of any other system design, VLSI design also starts
with the system specification in which the requirements of the chip under qevelopment are listed out.
The system specification captures information on 'what the chip does?', the input and output to the
chip, timing constraints, power dissipation requirements; etc. (e.g. For an IC for AND gate implementa-
tion, the intended function is logical ANDing of input signals and input per gate is 2 and output is 1).
The functional design or architectural design involves identifying the various functional modules in
the design and their interconnections. It represents an abstraction of the chip under development. com-
puter aided design (CAD) tools are available for architectural design. The functional aspects of a chip
can be captured using CAD tools with various methods like block diagrams, truth tables, flow charts,
state diagrams, schematic diagrams and Hardware Description Language (HDL). This process of enter-
ing the system description into the CAD tool is known as Design Entry. The truth table based design
entry uses the truth table of a logic function. This meth9d is suitable for the realisation of logic func-
tion implementation involving lesser number of logic. variables. The schematic capture based design
entry uses the schematic diagram created with an EDA tool (Please refer to the section on Schematic
Capture using Capture CIS of this chapter for more details on Schematic Capture). Flow charts can
also be used for design entry because of their inherent flow structure to describe any sequential flow.
State diagrams are employed to display state machines graphically. State diagrams are used for mod-
elling sequential circuits, characterised by a finite number of states and state-transitions. A Hardware
Description Language (HDL) based design flow involves describing the design (circuit) to be realised
in a Hardware Description Language like Very High Speed Integrated Circuit HDL (VHDL) or Ver-
ilog HDL. HDL~is.similar to software application programming languages but is used for describing
hardware. .
The functional simulation process simulates the functioning of the circuit captured using one of the
above-mentioned design entry techniques, using a functional simulation tool. During simulation, input
stimuli are applied to the circuit arid the output is verified for the required functionality. The logic syn-
thesis phase involving optimisation and mapping transforms the design into a gate level netlist corre-
sponding to the logic resource available in the target chip. The chip design may be for the development
of a custom ASIC or for implementation of the required functionalities of the IC in a standard Program-
mable Integrated Circuit like CPLD or FPGA. In case of CPLD, the logic gates are realised in terms
of the gates available in the macrocells of the CPLD, whereas for FPGAs the logic gates are realised
in terms of the Look Up Tables (LUTs). The optimisation and mapping process optimises the logic ex-
pressions for speed, area and power and maps the design to the target technology (FPGA, CPLD, etc.)
keeping their functionality unaltered. The physical design or layout design is the process of implement-
ing the circuit using the logic resources present in the final device (CPLD, FPGA) or creating the logic
partitioning, floor planr1ing, placement, routing, pinassignment, etc for a custom IC (ASIC), using a
 Embedded Hardware Design and Development

supported CAD tool. The Timing Simulation is performed using CAD tools for analysing the propaga-
tion delay of the circuit, for a particular technology like FPGA, CPLD, etc. For custom ICs (ASICs), the
physical design converts the circuit description into geometric description in the form of a GDSII-file.
The GDSII file is sent to a semiconductor fab for fabricating the IC. The IC is fabricated in silicon wafer
and finally it is packaged with the necessary pin layouts. The following section gives you an overview
of the VHDL based VLSI design.

8.3.1 VHDL forVLSI Design

Very High Speed Integrated Circuit HDL or VHDL is a hardware description language used in VLSI
design. VHDL is a technology independent description, which enables creation of designs targeted for
a chosen technology (like CPLD, FPGA, etc.) using synthesis tools. This enables one keep up with the
•fast development of semiconductor technology. VHDL can be used for describing the functionality and
, behaviour of the system (Behavioural representation), or describing the actual gate and register levels of
the system [Register Transfer Level (RTL) representation]. VHDL supports concurrent, sequential, hier-
archical and timing modelling. The concurrent modelling describes the activities happening in parallel,
whereas sequential modelling describes the activities in a serial fashion one after another. Hierarchical
model describes the structural aspects, and timing model models the timing requirements of the design.
Like any other programming language, VHDL also possess certain set of rules and characteristics. The
following table gives a snapshot of the important rules and characteristics specific to VHDL

. .

; 1\:SCII!characteritrsingl!i:quote. e.g: 'R ;''a;; etb

,,---·- •.:;t. _r"'"'~'" - ., . .t\ ' ',, ><-:;:i ·:?·;.··.·": -~ . ,:.
. . Opt1racters group~qin qqy)J.l~quqt~§; 'e.g. ;WQL';
•' \, ,: ,: ... , .,,.,A•v,:;.,
•_' • ,_,,,;~·,,• :,.' ' t " .:, ,,.,,;;: • ,._.:-,:' < <

Bit strings Arrays of bits with base Binary (B), Octal (0) or Hexadecimal (X).
e.g. B"I00" Only I and 0 allowed in string
0"127" numerals only 0 to 7. are allowed
X"lF9" Numerals Oto 9 and letters A to F, and a to fare allowed in string

Nunier;ils universal_integer do.es not includepoit1ts, e,g.100

universal real include a point, e.g.l?OJ ·.· . ·.•·. . . . . . ··. .•.· .. . . ~-
. The SP,~9~.l ch,!lracter fJ:~11ri•b.e:U§e,lfor,iµ9reasingtpe·read~~il~tye/{;l!l9:
. .· repreie~tea as. 1 boo:, : . . ..·\. J· : {:' .. · (:; . . · :'. 'c ,: .\ }Ji<
·•-Chara~t~r E tr Zc~ b~ µseqjf9~,in91~4~g¢kpp~~µt,:f!,t, lE. . .
) '#':, ~n b~e':usftVfor ~escrrB~g thi bait&fth~~#~~~~f~
. 2,~hdr§wes~.!lt(ng'nuniber 3}iBase Sat\ be betw~~nf~d
J"'' ,, '

· if statement if condition then

--Corresponding actions
else
--Corresponding actions
end if~. ,--~ -"
1
l
i
l

Introduction to Embedded Systems

The basic structure of a VHDL design consists of an entity, architecture and signals. The entity decla-
ration defines the name of the function being modelled and its interface ports to the outside world, their
direction and type. The basic syntax for an entity declaration is given below.
Entity name-of-entity is
Port (list of interface ports and their types);
Entity item declarations;
Begin
Statements; \
End entity name-of-entity

The architecture describes the internal structure and behaviour of the model. Architecture can define
a circuit structure using individually connected modules or model its behaviour using suitable state-
ments. The basic syntax of architecture body is given below
Architecture name-of-architecture of name-of-entity is
Begin
Statements;
End architecture name-of-architecture;

Signals in VHDL carry data. A signal connects an output and an input of two components (e.g. Gates,
flip-flops, etc.) of a circuit. A signal must be defined prior to its use.
 Embedded Hardware Design and Development

e.g. Signal a: bit; This is an example of a signal 'a' which can take values of type bit.
Once a signal has been defined, values can be assigned to the signal.
e.g. a<=' 1'; In this example a value' 1' is assigned to the signal 'a'.
Similar to software languages like 'C', where functions are stored in a library which can be re-used,
in VHDL also all compiled modules are stored in library. Packages are also stored in a library. A package
may contain functions, types, components, etc. For using components from a particular library, first the
library and packages must be specified in the VHDL code as

When a VHDL module is compiled, it is saved in the work library by default. As per the VHDL stan-
dard the work library is always visible and need not be specified in the VHDL code: If other packages
or libraries are to be used, they must be defined before the entity declaration.
e.g.

The above library definition defines that all data types, functions, etc available in the package std_
logic_1164 in the library ieee can be used in the underlying entity. As an example for VHDL based
design, let us consider the design of a D flip-flop. The VHDL description of the D Flip-flop is given
below.

If CLK='l' and CLK'event th~n

. Q
; "'''
<= D·
,
:End if;
· E_~d Process;
End DFF ARCH;

In the above example "DFF" is the name of the model and D, CLK, Q are the interface ports. The
architecture describes the internal structure and behaviour of the model. In the above example, the ar-
chitecture "DFF-ARCH" describes the D flip-flop function.
The HDL model of the circuit is then complied and loaded in an HDL simulator. The simulator en-
ables the designer to apply the input stimuli to the design and observe whether the output response is
as expected. If there are any functional errors, the HDL code is corrected and the design re-simulated,
till the design meets the furt~tional specifications. In the above example on simulation, by applying a
i clock and data inputs the model functions like a D-flip-flop. The design is now ready for synthesis. A
 Introduction to Embedded Systems

synthesiser tool compiles the source code to an optimised technology dependent circuit at the gate level.
The inputs to a synthesiser are the HDL code, a technology library, and constraints. The constraints are
in terms of the area and speed requirements of the circuit to be realised in the target technology. This
process is done in two phases:
D Q
Compilation: The HDL is translated to a generic netlist
Optimisation: The generic netlist is mapped to a target tech- CLK D l<'lip-
- - - f > ~ Flop
nology (ASIC/FPGA) satisfying the requirements of area and
speed.
On synthesis, the VHDL model described above results in a
D flip-flop to be reali~ed as shown in Fig. 8.24.
The next phase of implementation is physical layout (Place
and Route). In the case of an FPGA implementation, during the placement stage the various instances
in the netlist are mapped and their relative position inside the target FPGA resources is fixed. D,,firing
the routing phase, the interconnection between the various placed instances is done as per the netlist to
realise the circuit. Once the layout is complete, the final step is timing simulation. The design is now
re-simulated with the actual component and interconnect delays to verify the functionality. Figure 8.25
illustrates the various steps involved in a HDL based design.

(f:i~-~a,zs) :The,ll,DLba~edVLSl!D~sign Process

.... .,

Early embedded products were built around the old transistor and vacuum tube technologies, where the
designers built the PCB with their hands, oil paper, pencil, pen, ruler and copper plates. The process
of building a PCB was highly· cumbersome in ancient times where the designers sketch the ·requited
 Embedded Hardware Design and Development

connections using pen, pencil and ruler on papers and the finished sketch was used for etching the con-
nections on a copper plate and it took weeks and months time to finish a PCB. The more the inter con-
nections involved in the hardware, the more difficult was the process. The accuracy and finishing of the
PCB was highly dependent on the artistic skills of the designer. Today the scenario is totally changed.
Advances in computer technology and IT brought out highly sophisticated and automated tools for PCB
design and fabrication. The process of manual sketching the PCB has given way to software packages
that gives an automatic routing and layout for your product in a few seconds. These software packages
are widely known as Electronic Design Automation (EDA) tools and various manufactures offer these
tools for different operating systems (Windows, UNIX, Linux etc). EDA tool is a set of Computer Aided
. Design/Manufacturing (CAD/CAM) software packages which helps in designing and manufacturing
the electronic hardware like integrated circuits, printed circuit board, etc. The key players of the EDA
tool industry are Cadence, Protel, Altium, Cadsoft, Redac, Merco, etc. OrCAD, Cadstar, Protel, Eagle,
etc. are the popular EDA tool packages available in the market for PCB design. Of these, I feel Cadence
OrCAD as the most flexible and user friendly tool. The reference tool used for hardware design through-
out this book is OrCAD. An evaluation copy with limited features (for Windows OS) is available for
free download from the Cadence website www.cadence.com. Readers can use this tool for their hard-
ware design. Remember this tool is a demo version and you cannot use this for any commercial design
and it does not provide you the full features of the licensed version.

Install the demo version of the OrCAD Software for a PC with Microsoft® Operating System (Windows
XPNista or any other ver~ion supported by the tool). If the installation is succ~ssful you can see the
installed software under the group name OrCAD xx.xf Demo under the All programst tab which can be
selected through the 'Start' menu of your desktop. The 'OrCAD xx.xt Demo' contains three main tools
namely 'Capture CIS Demo'-The schematic creation tool, 'Layout Demo'-PCB Layouting Tool, and
'PSpice AD Demo' -The circuit simulation tool along with a set of documentation. Let us have a look at
these tools to get an idea on how they are used in PCB Designing.

Schematic is a way of representing the different components (can be an electronic component like re-
sistor, integrated circuit, capacitor, etc. or a mechanical/electromechanical component like push button
switch, relay, etc.) involved in a hardware product and how each components are interconnected to-
gether. You can create a schematic design either by hand sketch on a paper or by electronic sketch using
CAD tool. The OrCAD capture CIS tool is an electronic schematic design tool. To create a schematic
using this, execute the 'Capture CIS Demo' application. The following window will appear on your
desktop (Fig. 8.26).
Create a new project by choosing the 'New Project' tab from the File menu of Capture CIS
(File➔ New ➔ Project. .. )*. The following dialog box appears on the screen (Fig. 8.27).
Type a name for the project (say, for example, 805l_projectl). Choose the 'Schematic' option for
'Create New Project Using' and select a location for the new project by filling the 'Location' box and

t xx.x Represents the version number of the tool. If the version is 10.0, xx.x becomes 10.0
i The explanation given here is for Microsoft® Windows XP operating system
•The 'Menu' option may vary with change in version of the application. If you find it different from the one explained here, please refer
s to the user's manual of the application provided by Cadence.
j
 Introduction to Embedded Systems

( Fig. 8.27) New Project Creation U:sing OrCAD Capture CIS Tool

finally click the OK button. Now a schematic capture project is created at the specified location with
the specified name and the schematic tool opens default page (PAGEl) with various schematic draw-
ing tools on the right side for creating the schematic (Fig. 8.28). Close the default page by clicking the
page close button 'X'. Now you will be taken to the project window where you can view the following
categories.
On creating a new project, two files are created at the location for the new project with extensions
.op} and .dsn. The file names will be the same as that of the project name. The .op} file stands for OrCAD
 Embedded Hardware Design and Development

Design Resources

Outputs
t .\Project Name.dsn

Library

Referenced Projects

· B-· UI Design Resources.

;". (a.
l 1±]..,9 .\805l_projectl.dsn
j

L. 8]
!-:•.. ~ Library

ReferencedProjects

project file and it holds all project related settings for the project. The .dsn file represents the data source
name file holding the schematic drawing settings and data.
The .dsn tab in the project window is an expandable tab and it contains the 'SCHEMATIC' and
'Design Cache' details as shown in Fig. 8.29.
To start with the schematic design, double click on the 'PAGEl' tab under the 'SCHEMATIC I' node.
It will take you to the schematic drawing canvas along with the drawing tools on the right side of the
canvas. 'PAGEl' is created by default on creating a new project. You can change the name of it by right
1 clicking 'PAGEl' and choosing the 'Rename option'. The schematic drawing canvas details are given
in Fig. 8.30.
e
8.6.1 The Drawing Canvas
The drawing canvas is the area on which the different schematic components are placed and intercon-
s nected according to the requirements.
)
l
1
l
Introduction to Embedded Systems

· E;:J-- LJ Design Resources

· 8 .
~ \8051__projectLdsn
i EJ--·W SCHEMATIC!
) L_ ~ PAGE1
'· EJ,,, ~ Design Cache
L,,, § TitleBlockO
Ill
L.... t:i
, --Ll Outputs
L.{J Referenced Projects

Editing and zooming tools

Schematic drawing tools

Drawing canvas

Schematic drawings details

(.Fig. 8.30) Schematic drawing canvas

8.6.2 Schematic Drawing Tools

Schematic drawing tools are the various tools available in the canvas editor to place a compo~~t,
 Embedded Hardware Design and Development

(Resistor, capacitor, IC, etc), to interconnect different components (a connection between two points),
to add a text description, etc. The available schematic drawing tools and their usage are described in the
following sections.
" Place Part: Component placing tool. Place various components like resistor, capacitor, different
ICs, etc on the drawing canvas. Invoking this button pops up a place part dialog box as shown in
Fig.8.31.

AT76C1 OE/MISC
AT76C171 /MISC
AT76C176/MISC
AT87F51 /MICROCONTROLLER
AT87F52/MICROCONTROLLER
AT87F52/LCC/MICROCONTROLLER
AT8SC1051 /MICROCOMT ROLLER
AT89C1051 /SO/MICROCONTROLLER
AT8SC2051 /MICROCONTROLLER
AT89C2051 /SO/MICROCONTROLLER

~'F~g,8.3l) ·Selecting a componentto place in the schematic canvas

The manufacturer of different ICs and other components give them a Part Number/Part Name and the
component is identified by this name/number. OrCAD incorporates a number of libraries to incorporate
the skeletal drawing of these components. The library is located at the path /OrCAD Root Directory/
tools/capture/library, where /OrCAD Root Directory is the installation directory of OrCAD tool. You
can add these libraries using the 'Add Library ... ' button. Add the library you want by using this button.
Each library contains specific skeletal drawings. For example, the Library 'GATE' contains the skeletal
diagram (Pin Diagram) of almost all available Logic Gate ICs from different manufacturers. Similarly,
the Liprary 'MICROCONTROLLER' contains the skeletal sketch (Pin Diagram) for almost all com~
mercially available microcontrollers. If you are not sure about the component you are going to use
belongs to which library, select all libraries by pressing ·'Ctrl + A' key in the 'Libraries' box (remember
 Introduction to Embedded Systems

the libraries will only be seen in the Libraries section if you add the libraries explicitly to your project
using the 'Add Library' option). If you are certain, on which library the component you are going to
add belongs, you can select that particular library by clicking it on the libraries section. For example,
if you want to add AT89C51 microcontroller, you can go for two options either use the 'MICROCON-
TROLLER' library or use the entire libraries.
To select a component, type its name under the 'Part:' section. The part selector supports auto com-
plete for selecting part numbers. If you type the first few words of the part number, the .auto ·complete
will display the list of components starting with the typed part number. A preview of the selected com-
ponent is also shown on the right comer of the 'Place Part' pop-up dialog box. The 'Part Search ... ' func- ·
tion will help you to find out the library that contains a particular Part (component). Once you select the
part, click 'OK' button of the 'Place Part' pop-up dialog box. Move the cursor within the drawing canvas
and place the selected part on the desired location of the drawing canvas. Press down the mouse cursor
and then press 'ESC' key to end the place operation.

J.L_~_ _ _ _ _ _ _ _ _ _ __l:;;:;:':::i:~-~::JE!Z.--.==:::c,:::,-c::r~:r=•:'=:J ;::J

l.LiL_
;n~;•- .... -"~ ----------'--~-
........ ~•·•·'··----···-,--,, ------~
·, ~-~·~tt!frA
~
'"--
-····•--a,•-•·····- --- - - ~ ..tJ.. ··"
-~·100%--•-x~·1.2t"·Y;;i:is

( Fig. 8.32) Placing component in the schematic canvas

·'l_ Place Wire: Component interconnection tool. It interconnects various components like resistor,
- capacitor, different ICs etc within the drawing canvas. Choose this tool and click at the starting
point where the connection needs to be started and move the mouse till the end point of the connection.
The wire follows the mouse movement. Press 'Esc' when you are done with the connecting action.
/'t-.fi' Place Net Alias: Tool for interconnecting various components like resistor, capacitor, different
.· < , ICs, etc within the drawing canvas without using a direct interconnection using 'Place Wire' Tech-
niques. This is used if the number of interconnections within a drawing is large and complex. Clicking
this tool pops-up a dialog box to input the Net Alias name. Input the Alias name and-Press OK button.
 Embedded Hardware Design and Development

Now your mouse pointer carries the Net Alias. Move the mouse pointer to the start point where the con-
0 nection starts and place it there. Take the tool again, select the same Net Alias and place it at the other
end, where the connection needs to be terminated. If you add the same Net Alias each to different inter-
connection points, each of them gets connected together. The schematic diagram given in Fig. 8.33
illustrates the use of 'Place Net Alias' tool.
l-
Ul
Ul
e
PO.OiADO , 21
l- PO.I/ADI PO.OiADQ P2.0/Ag : 22
P0.2/AD2 PO.I/ADI
P0.2/AD2
P2.i/A9
~
P2.2iAJO ~
P0.3iADJ
P0.4/AD4 z P0.3/AD3 P2.3/All 25
;l::
e P0.5/ADS 0
F
:,:: P0.4/AD4 P2.4/Al2
J>2,5/Al3
26
P0.6/AD6
~
t P0.5/ADS
P0.6/AD6 P2.6/Al4
27
tS P07-AD7
zz "'z P0.7/AD7 P2.7/Al5
28

if PLO
Pl.I
0
u 8 PLO
Pl.I
RI
Cl
PU !OK
Pl.2 2OuF
PU
Pl.4 RI Cl Pl.3
Pl.5 !OK 2OuF Pl.4

T
Pl.6 Pl.5
Pl.i Pl.6
Pt.7
XTALI
XTAL2 XTALI
XTAL2
EA:VPP
RST EA.iVPP
RST
AT89C5l
AT89C51

Illustration
.
of using 'Place
,
N~f~ias
. .
', 'l'dol
-.,>.,': ·.-:-.,.;;~.,-;",

Place Bus: Places an address or data bus in the schematic. You can avoid connecting individual
wires of the bus one-to-one between the source and destination if this is used in combination with
the 'Place bus entry' Tool. For 8051, the address bus AO-A7 and A8-Al5 and the data bus DO-D7 can
be represented using this.
Place Bus Entry: Used in combination with the Place Bus Tool. It connects each individual lines
· of the bus into the common bus.
t:EIP Place P~rt:_ This tool associates a gr~u? of_connections tog~ther ~nd it is referred as port. Port
· · ·. connection 1s of three types; namely b1duectional connector, mcommg port connector and outgo-
ing connector. The bidirectional port connector cemnects a bidirectional port, e.g. DO-D7 of Data bus
(PO) for 8051. The outgoing connector implies that the corresponding port is originating from the device
(output line) and is intended to feed as an input-line to other devices. For example, the address lines of
8051, A8-Al5 -originates from the chip and it should be connected to the 1/p line of any other device
requiring these lines. The address lines (A8, A9, AlO toA15) are grouped using the 'Place Bus' tool and
r, each address pins (A8, A9, ... , A15) are connected to the address bus using the 'Place Bus Entry' tool.
g
Finally the bus is made available to the rest of the devices by connecting an outgoing Port to the bus.
1.
The port holds a name and if the same name is used by a bus with an incoming Port, it will givethe same
result as they are interconnected together directly. The same is illustrated in Fig. 8.34.
1t Place Junction: This tool places a junction implicitly on any part of the wiring. This tool can be
l~
used in the same way as other tools, click on the tool, move it to the desired point on the wiring
g
already done and press the mouse. Press 'Esc' Key to end the process.
1. tWR Place Power: Used for placing a power connection to the power line or to the power supply pin
;':.Q · of different components.
 Introduction to Embedded Systems

[A8 ... AI5]

Outgoing Port U2
Ul

21
P0.0/AD0 P2.0iA8 22 Bus tJ--4 AO DQO
PO.I/ADI P2.liA9 23 DQI
P0.2/AD2 P2.2/Al0 24
~ AA~
l . DQ2
P0.3/AD3 P2..3/AII 6 I AJ DQ3
25
P0.4iAD4 P2.4/Al2 26 D-t7 A4 DQ4
P0.5/ADS P2.5/AJ3 4 AS DQS
27
P0.6/AD6 P2.6/Al4 28 3 A6 DQ6
P0.7/AD7. P2.7/Al5 25 A7 DQ7

a-+
a-ti
PI.0
PJ.1
P3.0/RXD •
P3.IITXD
24
21
A8
A9
AIO
CJ.---t-', PI.2 P3.2/INT0 iJ
2
All
5 Pl.3 P.3.3/Imt 26 Al2
6 Pl.4 P3.4tro I Al3
Pl.5 P3.5fl'I Bus Entry
7 20 .61.:1
g Pl.6 P3.6/WR CE
Pl.7 P3.7/RD
WE Cl
XTALI ALE/PROG
Incoming Port
OE ~
XTAL2 PSEN
~
[A8 ... Al5) DSl644
EANPP
RST

AT89C5!

GNCi Place Ground: Used for placing a ground connection to the ground line or to the ground pin of
~? · different components. .
+~>!! Place No Connect: Some components may have some pins left unconnected. The No connect
·. .·., ·. tool is used for representing non-connected pins.
~{C ·Place off Page Connector: For modularity, the schematic can be drawn in different pages with
· each page representing the associated hardware for that particular module. For example, the sche-
matic can be drawn on different pages for power supply module, processor module, PC interface module
etc. If a connec_tion is required from one page to another page it is achieved by using the 'Off Page Con-
nector' tool. If a connection is going out from a page to other pages, it is represented using an outgoing
'off Page Connector' (Fig. 8.36) in that page and if a connection is coming into a page from any other
pages it is represented using an incoming 'off Page Connector' in that page.
• 8.6.2.1 Schematic Pait Creation, Formatting and Labelling Tools Certain parts may not be
available as readymade part in the Part library of the tool. In such situations, if you know the Pin number
for the part you want to create, you can create it using the following part creation tools. Labeling tools
are used for putting text labels and others in the canvas to give more readability and understanding of
the schematic drawing.
[J Place Rectangle: Creates a rectangle within the drawing canvas. This rectangle can either be used
- as an outline to a New Part to be created or as an outline to a labelling text or to isolate some part
of the schematic from other area to give visibility.
-~ Place Line: Used for creating Pins on the Rectangular Part for part creation. When used as a for-
. matting tool it is used for drawing lines to separate different areas of the schematic diagram.
 Embedded Hardware Design and Development

vcc
Junction -·--Power Connection

[A8 ...AI5]

UJ U2
0 00
N
"'" 21
P0.0/ADO 8 P2 .O/A8
i

22 AO
U
u DQO
PO.I/ADI > P2 .I /A9 23 Al > DQl
P0.2/AD2 P2 .2/ALO 24 A2 DQ2
P03/AD3 P2.3/All 25 A3 DQ3
P0.4/AD4 P2.4/Al2 26 A4 DQ4
P0.5/AD5 P2.5/AB 27 A5 DQ5.
P0.6/AD6 P2.6/Al4 28 A6 DQ6
P0.7/AD7 P2 .7/Al5 A7 DQ7
AS
PLO P3 .0/RXD A9
Pl.I P3 .I rI'XD AIO
Pl.2 P3 .2/INTO All
Pl.3 P3 .3/INTI A12
Pl.4 P3 .4ff0 Al3
Pl.5 P3 .5ffl Al4
Pl.6 P3.6/WR CE
Pl.7 P3.7/RD
19 WE A
18 XTALI ALE/PROG -OE zc.,
XTAL2 PSEN

No Connec EA/VPP
RST
A
z
0
[A8 ...Al5]
-"'"
AT89C51 ~
,f
--Ground Connection
;t

h
:-
e RXD)) Incoming off Page Connector
l-

g
:r Outgoing off Page Connector
--------~RXD
Cflg:8;36) Illustration of off Page Connecfor

Place Poly line: Tool used for creating poly lines on the drawing page.

d Place Ellipse: Place an elliptical shape within the drawing canvas.

rt
Place Arc: Tool used for placing different fonns of arcs and circle in the drawing area.

Place text: Tool used for creating text.labels for documenting the drawing and to add Pin names,
description, Part Number etc in the new part creation.
 Introduction to Embedded Systems

8. 6.2.2 Creating a New.Schematic Page As mentioned earlier you can provide modularity to the
schematic drawing by placing the schematic drawing of different modules in different pages. If your
drawing is a simple drawing you can use a single page. If the drawing does not fit into a single page, you
can create a new page by going back to the project window by closing the current page. (Don't forget to
save your changes © before closing the page you were working).
Refer the Fig. 8.29 ('Project view for new project showing schematic page view') for schematic
page view. In the schematic Page yiew, right click on the 'SCHEMATIC I' and select 'New Page'

8. 6. 3 Schematic Drawing Details

Whenever you create·a new schematic page, the schematic drawing details entering table gets attached
to the bottom right comer of the page by default. Figure 8.37 illustrates a schematic drawing details
template.

Title
<Title>

Size Document Number Rev

A <Doc> <Rev( ode>
Date: Thursdav. December 22. 2005 I Sheet l of 1

( Fig. 8.37) Schematic drawin9,"defails tem~late

The 'Title' section is used for entering the title of the Schematic (e.g. 8051 Evaluation board). You
can also add the name of the person who carried out the drawing. 'Size' indicates the size of the drawing
page. To get the details of the 'Size' take the 'Schematic Page Properties ... ' tab from the 'Options' menu
when the page is in the opened state. (Options ➔ Schematic Page Properties). Whatever values you set
there is taken as the default value for a page.
The document number should be given according to the format specified by the QA standard you are
following, e.g. ISO standard. 'Rev' gives the version number of the drawing (Version number increases
with each revision). Date represents the date on which the schematic is created. 'Sheet No.' represents
the Sheet/Page Number in a multi sheet/page drawing. Out of these 'Title', 'Document Number' and
'Rev Code' is very important in reviewing the document. A typical schematic drawing details table is
illustrated in Fig. 8.38.

8051 Evaluation Board

Size Document Number Rev I
A PROJ CODE: 001 2
I
!Date: Thursdav. December 22 · 2005 I Sheet of 2 I
( Fig. 8.38) Schematic drawing details table
 Embedded Hardware Design and Development

I hope the basic lessons of schematic design creation and how different tools are used for creating
a schematic diagram has been covered in this section. Now let's create a complete schematic diagram
using the Capture CIS tool (Fig. 8.39). Part of this schematic (Power Supply Part) is available for down-
load from the Online Leaming Centre web page of this book.
,(vcc
RN1 vcc
"' JACK1 01 U2
LM7805C
4,7K
IN
R1 Q
21 8.2 z
PO.O/A008 °P2.0/A8
P0.1/A.01 > P2.1/A9
P0.2/AD2 P2.2/A10 02
"
P0.3/AD3 P2.3/A11
PMIAD4 P2.4/A 12
RED LED
PO.SiAOS P2.51A.13 'f, 7
P0.6/AD6 P2.6/A14
P0.7JAO7 P2.7IA15
1 Pl .Olf2 P3.IJ,R)(!) 1-,;;10'---,,,...

~nlf2•EXn~
P1.3 P3.3Am'T
h-'SlE3~ P0WER SUPPLY PART

-'" "'" "'-'-_~·: :~ ~i~= I-ii----

P1.4 P3.4/TO
P1.5 P3.5/T1

i-c---~•lCTAL1 AL~
□v C7 ,
adj0 .. 71
l'1lm
----'•....' ~ZHzi ~~J 1--.r--+-f.-
9
1MFO+ U3
03 u V- 17
1N414$
12lN ~ V-
V+
T20UT C2·
C2-
R2OUT C2+
C2•
Pt R.21N C1-
LCD & BACKL!GHT CH
3
RiOUTt--i- ~
""+'i------iT10UT T11Nl-"---
.,_..._ _ __.4 RHN~ ~

" "
RS232 009 CON

01 RS-232C INTERFACE
8C547B 1-----"'BAC=K'-LIGH'-"T

"' Simple 8051 Evaluation Board

1ze ocumen um er ev
A PROJ_CODE:001 2

ate: .,eet
0 '

(Fig:;~.39) Finished schematic:

i
s Once the schematic is finished, part numbers should be assigned to the various components present
in the schematic and error checking should be perfonned. If there are no errors, you can proceed to the
next step, the netlist creation. The following sections illustrate each of these steps, namely 'Part Number
Creation', 'Design Rule Check' and 'Net List Creation'.

8.6.4 Creating Part Numbers

Part Number is the name assigned to each component in the schematic diagram. It is required to identify
and distinguish the components in the schematic diagram. Normally part number is given in the order
in which they are present in the schematic page. Certain naming convention rules are followed for this.
For example, capacitors are named with the letter C with suffix x (Cx where x = 1, 2, 3 .... ); resistors
are named as Rx (x 1, 2, 3.... ) and ICs with Ux, etc. This is automatically validated by the design tool
itself, if you follow the steps listed below. The suffix 1, 2, 3, etc. are allocated by the tool depending on
 Introduction to Embedded Systems

the relative positioning of the component within the schematic Page (x and y co-ordinates of the com-
ponent). The topmost component is given the reference number 1 and reference number 2 to the next
component, and so on. .
To generate automatic Part numbers, close all sehematic pages and come back to the project view and
highlight the dsn name or schematic name (In our example the dsn is '8051 _projectl .dsn' and schematic
name is 'SCHEMATIC I'). Click on the 'Tools' menu from the main menu associated with the project.
Select 'Annotate ... ' The following window as depicted in Fig. 8.40 pops up on the screen.

From the pop-up window, select the option 'Update .entire design' for' Scope', 'Reset part referenc-
es to "?"' for 'Action' and 'Update Instances' for 'Mode' and then press the OK button. This prompts
for a confirmation. If you respond yes to the confirmation, every part number is re-set with "?" ('C?',
'R?', etc.). If you open the schematic page you can see this. The action performed is to reset all refer-
a
. ences to default value. To assign the part numbers, go to the 'Tools' menu again and take 'Annotate ... '
option. The same window pops up. Choose the option 'Incremental reference update' for 'Action' item
and keep the rest same as the above settings. Pressing 'OK' button prompts again for user confirma-
tion and if you confirm it, the design part number is updated automatically. It is to be noted that no two
components will have the same Part Number. Eventhough there are two or more capacitors or ICs or
resistors present in the schematic diagram with the same values (e.g. O. lMFD (Microfarad) for capacitor
or 8.2K (kilo ohms) for resistors, etc.) different part numbers should be \!Sed for them. Part numbers are
· very helpful in PCB routing, soldering of components in the finished PCB and in the creation of Bill of
Materials (BoM).
 Embedded Hardware Design and Development

. s.6.5 Design Rules Check

Design Rules Check (DRC) is performed for checking any possible errors in the schematic d~ram,
like duplicate part references, missing off-page connector connections, unconnected nets, unconnected
power and ground pins, etc. For performing the DRC check, highlight the dsn name or schematic name
from the project window and select 'Design Rules Check ... ' option from the 'Tools' menu. The follow-
ing window as shown in Fig. 8.41 pops up .

.•. #'Itp settings wind~w

Select the option 'Check entire design' from 'Scope', 'Check design rules' from 'Action'. Check the
following options among the.'Report' category by selecting the corresponding check box.
Report
• Create DRC markers for warnings
s • Check hierarchical port connections
• Check off-page connector connections
• ReportW.enticalpart references
• Report invalid packaging
n • Report hierarchical ports and off-page connectors
• Report visible unconnectea power pins
• Check unconnected nets
• Report all net names ,\
You can select the location for the DRC report file to be created. By default it is generatedwith name
'project name.drc' (e:g. 8051 _projectl.drc) and it is created at the project location directory.
The .drc file gives you the details of any errors present in the schematic along with the poi11t (x & y
co-ordinates) in schematic diagram where the error is,~curred. Sometimes the .drc may report warn-
ings. You can ignore some of the warnings. But you must look into the warnings and should confirm that
I
 Introduction to Embedded Systems

the warnings will not create any issue in the total circuit. Examples of warnings that may be ignored are
"Bi-directional pin connected to input pin", "Output pin connected to Power line". The second example
is a very common one where the o/p pin of regulator gives the regulated supply and it usually gets con-
nected to the power pins .of other ICs in the circuit. Here, though the o/p Pin of the regulator IC is giv-
ing the o/p power, the 'Pin Type' '3/ill be output and you are connecting that pin to a 'Pin Type' power
of other ICs. This is a possible Pin type conflict. You can either discard this warning or can avoid this
warning by changing the 'Pin Type' of the regulator o/Pi Pin to 'power' by right clicking the Regulator
in
IC component the schematic and choosing the 'Edit Part' option. Double click on the pin, for which
you want to chang~ the 'Type:, choose the desired type.
Don't ignore all warning~ blindly. First look at the warning and understand its consequence in the
schematic. If you are sure that it will not create any impact on the schematic, simply ignore it or if you
have enough time, re~tify it by.resolving the condition that created the warning.

8.6 ..6 Creating Bill of Materials

Bill of Materials (BOM) gives the list of various components (in terms of component type and value)
present in th'e schematic and their quantity. BOM gives the exact number of components required to
fabricate a board and so it plays a vital role in cost estimation and component procurement. When a PCB
is fabricated, it contains only the part number of the components (like Rl, Cl, C2, Ul, etc.). BOM is
the cross-link chart which gives the component value for the part references listed on the PCB. Bill of
Material is a useful infonnation for the person who assembles the various components on the finished
PCB. For generating the BOM of the schematic, go to the Project Window, highlight the .dsn name or
schematic name in the Project window as mentioned e.arlier, select 'Bill ofMaterials ... ' option from the
'Tools' menu (Fig. 8.42).

( Fig. 8.42) Bill of Material (BOM) creation

 Embedded Hardware Design and Development

Select 'Process entire design' from 'Scope' and 'Use instances (Preferred)' from 'Mode'. The de-
fault location for the report file is the Project directory and the BOM name is the project name with
extension .bom. You can change the report :file location by giving the desired path name in the edit box
present in the 'Report' section. Press 'OK' to proceed. The BOM is generated automatically and it is vis-
ible under the 'Outputs' section of the Project Window. The BOM can be opened for viewing by double
clicking on the .bom file. A sample BOM :file is shown in Fig. 8.43.

in:iple 8051 Evaluation Board

PROJ CODE: 001 Revision: 2

Bill Of Hate:rials January 1,2006 22:25:00 Pagel

f
i !terr Reference Part

1 3 Cl,C3,C9 0,1HFD
1 C2 220uF/25V
3 1 C4 0.luF
4 2 cs,ca 22pF
5 1 C6 10 MFD
6 1 C7 lHFD
/
7 1 D1 1N4007
e 1 D2 RED LED
9 1 D3 1N414e,
10 1 JACKl POWER
11 1 Ji LCD
12 '
-'-- Pl RS232 D:39 CON
13 l Ql BC5473
14 .;. RNl 'L?i<

I 15
16
3
.
-
Rl, R2, R3
R4 5K POI
;:, ,2 ~

17 - Ul AT,S9C52
lE ' U2 LM7805C
19 l U3 l-L'l.X:233
20 .i Yl 11.059 HHz

tfig~ 8,.43) Sample BOM

 Introduction to Embedded Systems

If you observe the BOM closely, you can find that the BOM gives different types of information to
the different type of users. Take the first item in the BOM list. For a person who is interested in procur-
ing the components, the first line of BOM gives the information on the quantity required for capacitor
with value 0.lMFD per board is 3. For a person who is involved in the assembling of components on
the board, the first line gives the information, the part numbers with reference values Cl, C3, C9 should
be soldered with 9apacitors with value 0. lMFD.

8.6.7 Netlist Creatio;n

'Netlist' refers to the representation of interconnection of various components within the schematic
diagram. If the PCB design is viewed as a step-by-step process, schematic creation is the first step,
layout creation is the next step and PCB fabrication is the final step. 'Netlist' is the output of first step
(schematic) and th1s is fed as input to the second step (layout creation).
In general, 'Netlist' is the soft form representation of the different components present in the sche-
matic and the hard wired connections required among the various components. Creation· of 'Netlist'
from the schematic design varie,s depending on the type of tool used for 'Layout creation'. OrCAD
schematic design tools provide support for different kinds of layout tools and depending on the type
of layout tool, the steps involved in 'Netlist' creation varies. We will discuss the creation of 'Netlist'
for two different Layout tools namely 'Layout'-which is part of the OrCAD EDA package itself and
'Allegro' -The second product line from OrCAD for layout design.
For creating the 'Netlist', highlight the dsn name or schematic name from the Project Window
and choose the 'Create Netlist ... ' option from the 'Tools' menu. The following window as shown in
· Fig. 8.44 appears on the screen.

I
I
I
 Embedded Hardware Design and Development

If you plan to use OrCAD 'Layout' as the layout tool, select the tab 'Layout' from the pop-up win-
dow and select the options as given in Fig. 8.44 and proceed. The 'Netlist' is generated automatically
with extension .mnl and it will be shown in the 'Output' section of your project window.
If Cadence 'Allegro' is your layout tool, select the tab 'Other' instead of 'Layout' from the 'Create
Netlist' pop-up window as shown in Fig. 8.45.

~~!\:l-Jk45} Netlist Creation for 'Allegro' Tool

Select 'telesis.dll' from tlie 'Formatters' option and change the 'Netlist' file creation directory if you
want (By default the 'Netlist' file is generated at the project directory with same name as the project
name and extension .net) and press 'OK' to proceed. ~-,►-
The 'Netlist' file is generated automatically and it is visible in the 'Outputs' section of the project
window. If you open the 'Netlist' by double clicking the .net file from the 'Outputs' section, a file de-
scribing the various nets is displayed. A sample 'Netlist' file generated in 'telesis' format for "Allegro"
layout tool is shown in Fig. 8.46.
On a closer look at this file, you can find that it is a representation of the packages (will be described
,,iµ a later section of this chapter) for various components of the schematic and a 'soft form' representa-
tion of the interconnections among the components present in the schematic. The .net list file contains
m:oisections namely-PACKAGES section and NETS section. The packages section defines the pack-
ages of different components in the schematic and the NETS section lists out the various connections in
 Introduction to Embedded Systems

0.1MFD! 0.11-!FIJ; Cl
220uE/25V! 220uF/25V; C2
O.lMFD! 0.1MFD; C3
5: O.luF! O.luF; C4
: -22pF ! 22pF; CS
10 MFD! 1.0 MFD; C6
lMFD ! ll-1:FD; C7
22pF! 22pF; C8
O.ll1FD! 0.1MFD; C9
1N4007! 1N4007; Dl
RED LED! RED LED; D2
1N4148! 1N4148; D3
LCD! LCD; Jl
KLD-0201-DC FOWER CON! POWER; JACKl
RS232 DB9 CON! RS232 DB9 CON; Pl
BC547B! BC547B; Qi
8.2 R! 8.2 R; R1
8.2 R! 8.2 R; R2
8.2 R! 8.2 R; R3
SB POT! 5K POI; R4
4.7R! 4.7R; RN1
ATS9C52 ! AT89C52; Ul.
LM7805C! LM7805C; U2 ,
MAX:233 ! MAX233; U3
11.059 MHz! 11.059 MHz; Y1
$NEIS
N1274902; JACK1 . 2 D1 .1 JACK1 • 3
N1274894; C2.1 C3.1 U2.1 D1.2
N1178213; Ul.31 R2.2
N12043990; D2 .1 Rl. 2
ADS; Ul.34 J1.12 RNl.3
AD7; Jl.14 U1.32 RN1.1
RXD; U1.10 U3. 3
RW; J1. 5 Ul.13
AD3; RN1.5 J1.10 Ul.36
N21285; CS.1 Ul.19 Y1.2
RS; Jl. 4 Ul. 12
~w : ,T1 • fi .m . 1 4

the schematic. A group of connections is given a net ,name. and the component parts Which are getting
interconnected at that net are listed against the net narile. In. the net list file given above, the first net is
 Embedded Hardware Design and Development

named as Nl274902 and it represent the interconnection of Pin 2 & 3 of Jack JACKl and Pin 1 of Diode
DL You can verify this interconnection by referring back to the schematic diagram in which Pins 2 & 3
of JACKI is connected to Pin 1 of Diode D 1. The '.net' file is fed as input to the layout tool for generat-
ing the PCB layout.

Layout design is the process of creating the blueprint of the actual PCB from the 'Netlist' file. The layout
file generated for a 'Netlist' file is given for the final PCB fabrication. Wheneverwe plan to build a new
house, we usually approach a designer to build the 'plan' for the house. The 'plan' contains all informa-
tion regarding the house, like number of rooms, area of each room, window and door positions for each
room, null)ber offloors (single or multistoried house), etc. A 'Layout' file is similar to the 'plan' for
a house in the sense, the 'Layout' file contains the information on different components present, their
physical appearance (footprint), the component placement, interconnection among the components,
number of layers for inter connection etc for the PCB.

8. 7.1 The Building blocks of Layout

Before going to the details of the usage of the 'Layout Tool' let's have a brief discussion on 'What is
meant by Layout file creation and what all are there in the layout file'. 'Footprints', 'Routes/Traces',
'Layers' 'Vias', 'Marking text and graphics' are the basic building blocks of Layout.
8.7.1.1 Footprint (Package) Footprint is a pictorial representation of a component when it is
looked from the top (top view of a component). It is a 1: 1 representation of the bottom portion of a
component. Imagine you have a chip and a sand-filled box in your hand and if you place the chip on
top of the sand-filled box and press it gently, you will get the exact impression of the chip including the
body and pin shape of the chip when the chip is removed from the sand. This is what is exactly meant
by a footprint.
Package and footprints are two identical terms used interchangeably in PCB layout design. In layout,
both the terms represent the same identity. But technically they are two different entities. Footprint can
be viewed as a subset of package. Package is a three-dimensional drawing showing all measurements
of the component, viz. length, width, thickness for the body as well as pins of the component. Package
drawing contains 'Top View\ 'Side View' and 'End View' of the component. Out of this, 'Top View' is
important in PCB layout design. It gives the space requirement for the component within the board, the
orientation of pins, width of pin holes (for through hole components) and the size of pin pads (for sur-
face mount components). The 'Side View' and 'End View' of the component have nothing to do with the
board space requirement except in cases where a plug-in board is supposed to put on top of the current
board. 'Side view' gives an idea about the component height. In layout, the 'Top view' of the component
is known as 'Footprint;.
Different manufacttires produce same chip/component with different names and a large number of
chips/components are .available in the market. If each manufacturer starts developing chips/components
with their own pacld1.ge, it will be very difficult for a layout designer to create a footprint for all. Hence
there is a standard for packages and each chip manufacturer should develop chips according to any
g one of the standard packages supported. The standard package's footprint is available as library in the
is Layouting Tool and the layout designer can choose that 'Footprint' for a component. Some of the com-
monly available packages ar.e explained. below.
 Introduction to Embedded Systems

Single In-line Package Single In-line Package is a single line package where the pins, are arranged
in a single row with specific pitch spacing. The pins can be either 'Through hole' pins or 'Surface
mount leads'. For 'Through hole' pins, the footprint represents the number of pins by drills or vias and

1 10

· 10 Pin Single In-line Packages (SIP) Through Hole

1 10

10 Pin Sin2le In-line Packa2e (SIP) Surface Mount

the dimensional details of the drill are same as that

of the pin dimensions. ILthe pins are ~urface mount
pins, they are represented in the footprint as pads.
For 'Through hole' pins, the first pin is indicated by a
square pad with a drill/via. The footprint of a 10 pin
Dimensions in Inches and (Millimetres)

--- 2.07(52.6}
2.04(51.8) ---, pr
t
.566(14.4}
SIP package is given in Fig. 8.47. SIP package is com- .530(13.5)
monly used for connector parts. _l
Dual In-line Package Dual In-line Package (DIP) -H I-+- .090(2.29}
is a commonly used 'through hole' package for Inte- .220(5.59}
I
+- 1.900(48.26) REF ---+1 MAX
-+11-+- .005(.127)
SEATIN:T\Trnt ~ lnrd_l_
grated Circuits from the early days of IC technology.
DIP contains chip body and through hole pins on both MfN

sides of the body of the chip. DIP package itself is

varying, depending on the body width of the IC, the
PLANE rnI ~~· ·uTT
.161(4.0~) II
.065(!.65)
.0.16(.381)

pin spacing (lead pitch), etc. The commonly used DIP

.125(3.18 I- .065(1.65)
_.. - .022(.659)
.014(.356)
:110(2.79} .041(1.04)
is with 1 inch pin spacing and 0.3 inch to 0.6 inch
Ir
.090(2.29) .630(16.0)
body width. The number of pins for DIP varies from .590(16.0) j
8 to 64 in an even number multiple. An example of . - - ~ ~REF
the package drawings and footprint of DIP is shown .012(.305) --1/-~1\3
in Fig. 8.48. .008(.203)
1_ •
690(
11.s) I
1.610(15.5),-, ·
The body of the chip is encapsulated in plastic, c.e-
Fig. 8.48 Package DraWing for 40 Pin Plastic
ramic or some other matet~al. Depending on this, the Dual In-line Package (PDIP)
Dual In-Line Package is named as PBIP{Plastic DIP), Courtesy ofAtmel (www.atmel.com)
CDIP (Ceramic DIP), etc. (see Fig. 8.49). . .'
 Embedded Hardware Design and Development

Zigzag Inline Package (ZIP) ZIP package is a modified

fonn of DIP. DIP contains leads (pins) symmetric to both sides
of the body of the package, whereas ZIP holds pins in a zigzag
manner as shown in Fig. 8.50.
If you observe this package, you can identify that the pin
numbering for this is entirely different from that of the DIP. In
DIP, the pins are numbered in incremental order in one direc-
tion starting from the topmost pin (Left topmost pin) and on the
second row the pin numbering continues from the bottom pin
(Right bottommost pin) whereas in the case of ZIP, the pins are
arranged in zigzag form and the numbering of pins also is zigzag
starting from the first pin as shown in Fig. 8.50.
Small Outline Integrated Circuit (SOIC) Package SOIC
is a rectangular surface mount package with eight or more gull
wing leads. The leads protrude from the longer edge of the pack- 2
age. SOIC packages come in a variety of body widths, namely
· narrow body (150 mils (1 millimetre 39.37 mils)) and wide
body (300 mils). The standard SOIC lead pitch is nominally
50 mils (1.27 mm). The pin count for SOIC p~age varies from
8 to 28 Fig. 8.51. i 3
Thin Shrink Small Outline Package (TSSO,P) Thin
shrink small outline package is a surface mount package with
very small body size and smaller lead pitch. TSSOP comes in
the following sizes 3.0 mm x 0.85 mm (Width x
Height), 4.4 mm x 0.9 mm (Width x Height) and
6.1 mm x 0.9 mm (Width x Height). Lead count for
TSSOP ranges from 8 to 56. Its standard lead pitch
is 0.65mm. The package drawing details of TS SOP
is shown in Fig. 8.52.
Quad Flat Pack (QFP) So far we discussed about
packages with leads (pins) only on the two sides of
the body of the chip. There are chips with leads/
pins on all four sides of the chip. These chip pack- El'JDVIEW
ages are called Quad Flat Pack (QFP). QFP itself is
available in different packages namely Plastic Quad CON!ltON. 0 li'lENSIOHS
(Unitd:l-1$aet.1$•fflm)

.... I !
Flat Pack (PQFP), Thin Quad Flat Pack (TQFP), &'llll!Oll
.4 i 1,3$
HO•
- i
MAX i HOTE
l.7S I

(VQFP), etc. A footprint of 84 pin PQFP is shown in At O,lO - =I

b 0.3! - I o.s, I
Fig. 8.53. C I 0.17 - I 025 I
0 : ,ti<)
...., - j MS I
With this we are -concluding the discussion on El - I 3.\111 I
SIDE VIEW C ~7l) - ! C2fl
footprints/packages. There are lots of other pack- • U795C

ages/footprints remaining. Describing all of them

L

'
D.40

0'
-
-
!
! ..
'"'
in detail is beyol\ld the SGope of this book. The aim
~:r.~:~:~io ;:i::g;!v:n!ethr:~:!o~~~cu:d ;1'!J,~;51~,
0
~
. \for'lf:P.tttiSOIC.
r~.~~;tc;my ·
 Introduction to Embedded Systems

3 .2 1

Pin I Indicator
this comer

L1
I

N -tt-
L
Jop Vif!W End View
COMMON DIMENSIONS
(UnitolMeasutl>=mm}
SYMBOl MIN NOM MAX NOTE
D 2.90 B.00 8,10 2,6
E 6AOBSC

--
~ . j__J_
t
E1
A
4.80
-
4.40
-
4.50
1.20
s.,s

E
,
I~ A2 A2 0.60 1,00 1.05

- - 0 - -1 h 0.19 - 0,00 4
e 0.f.6BSC
Side View L 0,45 QllO 0.75
L1 1mREF

111111111111111111111
=
---=- •
11- tt,
---=
----
- ---- -===
=1 N
N

111111111111111111111

( Fig.8.p3) Foe>q>rintof8{;Pitl;POFP ,'

(C911.rt~;y
,:,~- . ,. . .
,. , '
o{Cadenc:e OiCAI))

packages in layout design. Interested readers ~re requested to visit the websites www.atmel.com and
www.maxim-ic.com for getting additional details
. on packages.
.
·
8. 7.1.2 Routes/Traces 'Routes' are the interconnection among the pins/leads of various com-
ponents. In schematic capture, it is represented as \an electrical connecti~n line. Whereas in layout,
the interconnection is represented as copper track interconnection among the leads/pins of different
footprints. This copper interconnection is knqwn as 'PCB Track'. The width of the copper track can
I
 Embedded Hardware Design and Development

be set to various values during layout to represent

tracks with different widths. Commonly used track
20mil Track
CON2 0 .1 MFO
widths are 5 mils, 7 mils, 12 mils (1 mm= 39.37
mils), etc. Proper track width should be allocated to LM7805C~
tracks connecting to power supply line and ground 1 .....,._.....
L.>.

line. Some reference chart is available for determin-

ing the minimum track width required for carrying
a particular current (e.g. For carrying a current of
500 mA, the track width should be minimum ·1
12 mils, etc). The routes and footprint of a PCB
layout are shown in Fig. 8.54. Ul
8.7.1.3 Layers 'Layers' act as the 'Multiple Footprint
12 mil Ttack
planes' for performing the routing operation, if {Package)
the number of interconnections in a design is high .
. Normally the routing is done on the top and bottom
layers of the PCB. If the complexity of the circuit
increases, additional layers are added in between the top and bottom layers and the track routing is done
on this layers. It is also advised to allocate separate layers with copper spreading for power supply and
ground connections. This avoids noise and electromagnetic interference issues in printed circuit board.
8.7.1.4 Via In a 'Multilayer' board, the interconnection among various layers is provided through
conductive drill holes. These drill holes are known as "via'. Drilling is done on the physical PCB using
Computer Numeric Control (CNC) drill machines or laser drills. The drilled holes should be copper
plated or riveted (Inserting a rivet into the drill hole) to establish the necessary inter-electrical connec-
tion among the various layers. 'Vias' are also known as through holes. If the through hole is.plated or
riveted for establishing electrical connection, it is called 'Plated Through Hole (PTH). If non-plated, it
is referred as none-PTH. Figure 8.55 illustrates 'via' and 'PTH' in PCB layout.

lNllQQ,7
IJ 1 loner Layer 1
Top Layer

8. 7.1. 5 Marking Text and Graphics Marking text and graphics provide information like part
number, part name, polarities 9f polar components (like capacitors, diodes, etc.), pin number, product
name, company name, board name, graphic outline of components, etc. These text and graphics are
printed on PCB after fabrication (Fig. 8.56). Refer to section Silk Screen for more details.
 j
l •
I
:I
I
~

Introduction to Embedded Systems

Part Name
(} • H1 F" D /-
_,,.,,.

U17$~5C ~
l l
~......iF,I

8. 7 .2 Layout Design with OrCAD Layout Tool

To create a PCB layout using OrCAD Layout tool, execute "Layout Demot" from the 'Start Menu'. You
can see the following tool window on your PC screen (Fig. 8.57).

( Fig. 8.57J OrCAD Layout Tool

t The name given here indicates the name of the demo version tool. It may be different for the commercial version of the tool. Please
refer to the OrCAD documentation for more details.
 Embedded Hardware Design and Development

Select 'New' from the 'File' menu. A pop up window (AutoECO) describing the inputs to be fed to
the tool appears on the screen (Fig. 8.58).

·.· ,lnpu( La;~clfcH'.ttfPL iri,1llX fiiii

.. Je:\OrCA~\OrCb.D_1o:o~Dem~\;~o;s~ayou;\dat:;~defau!Uch

•, lnputMNL net11lfj;''. .
' •• ' >

D:\OrCAD\Schematic!\PO\Y'ER_SUPPLY.MNL

Output La.~out'M!IX file .

1

•· jo:\OrCAD\Sche~1a;i~~\POWER_S"u PPLY-3r~ax

L ~tart<i r\e\f>I ~9~rd file, , :, \. . .· .·· . . . ..

. · Choq;eanapprOP,iiate techr\o!qgy onemplatelile asyo~rinput TCH file.
If 1-<pdafog an ~~i~.ting board, nets Md comppnents will be updalj9d.
· N6property c~i\)e}pn eKiftin\i'nets arii:I i:oQ1porietits (rKIFbcitprji1fohariges)
• -': ·•--: • • • ..' > .,,.- ;

r '\,/hena pad's net chaqges,JipuJ'.l.the entire lr<:1ck /,~1-~!lfl;jus\·\heJast s~ment

An~• special switches gi;en toy~". b;. ~de~c~ ~u;;om;; ~-tJp~oit
' ' .
' ,-: · ·• · , .
; ~

ApplyEcg I Help ] -~J.

[Fig.'8.'58) Creating a New PCB Layout using Layout Tool

The AutoECO pop up window contains the following sections.

Layout TCH or TPL or Max file This is the reference template and you can select the _default.tch
file for this. Clicking on the 'Browse' button by the side of the edit box for this section guides you to the
directory containing the tch/tpl/max file. Select '_default.tch' from it.
Input MNL netlist File This is the section for inputting the 'Netlist' file created using OrCAD 'Cap-
ture CIS' schematic design tool. The file extension of the 'Netlist' file specifically created for 'Layout'
in the Capture CIS tool is '.MNL'. This 'Netlist' file, containing the component information and com-
ponent interconnection is going to be transferred to a PCB layout format. ln our case the netlist file for
the design for power supply part of the 8051_Project is POWER_SUPPLY.MNL
Output File Section This is the O/p file generated in iayout corresponding to the .MNL 'Netlist' file
input. By default its name appears same as netlist name and the file extension is '.MAX'
 \
ll
'

Introduction to Embedded Systems

Select the default values for all other options and press 'Apply ECO' button to create the new layout
file. The 'Netlist' is processed and if it is error free, the layout tool associates each component's package
(footprint) as per the 'Netlist' file. The 'Netlist' file associates a package to each component as per the
package value given for each component given in the schematic diagram (which is created using Cap-
ture CIS). To assign a package value to a component at the time of schematic design itself, right click the
component ip_ the schematic page and edit the package information from 'Edit Properties ... ' section. If
you do not assign the correct package name to a component during schematic creation, a default pack-
age is associated to the component. You have to search the layout library for the different package names
corresponding to the various packages. If the layout tool is not able to find out a package associated with
a component, at the time of layout creation, it will prompt for the package name for the component.
You should select a package for the corpponent from the existing component library or should create
a new package if the package is not present in the library (refer to layout package creation and usage
documentation by OrCAD for more details). In our power supply example we haven't associated any
package name for any of the component during schematic design with Capture CIS. Hence the layout
tool will prompt for the package for each component is shown in Fig. 8.59.

t
I
'
(

Select the option "Link existing footprint to component. .. " and link a footprint to the component 1 s
(Fig. 8.60) t
The set of available footprint libraries and the. footprints available in the selected library is listed on I
the footprint selection dialog box. As you move between different footprints, its preview also is shown
on the selection dialog box. Since we are using the demo version, the number of footprint libraries and (

footprints within each library are limited. Select the footprint fitting to the package of your component C
in terms of size; Repeat the selection for all components. C
On completion of the footprint assignment and 'Netlist' verification, Layout generates an 'AutoECO' C
report describing the errors, if any. Accept the report if it i~ error free. Now you can see the package of C
various components placed on a layouting canvas (Separate Window along with the drill chart). The in- };
terconnections among various components are represented in the form of lines as shown in Fig. 8.61. f
f
8.7.2.1 Board Outline Creation To start with the physical layout process, the firststep is assign-
~
ing the physical board size (PCB size in length x width) to the layout area where the components are
 Embedded Hardware Design and Development

Bl,.KCON.1 /w.200/10
BLKCON.lOONH/T!,jalE/w.200/20
BLKCON.lOONH/TMalE/W'.200126
BLKCON.lOONH/TMalE/w.200/40
BLKCON.156NHITM1SQS/w.312/6
DINC/MIN SM/6/A
DIP.100/24/w.300/ll.250
OSUB/RP.318/TM/15
JUMPER200
OSC8\4P
PLCC«

going to be placed. For this, the datum (reference point} ne_eds to be fixed first. Move the datum to a
convenient location using the command 'Move Datum' from 'Tool' menu (Tool ➔Dimension➔ Move
Datum). Place.the datum at the desired positi(!n by clicking on the desired point on the layout window
after executing the 'Move Datum' command. Press 'ESC' key to exit the command. Move the drill chart
to a convenient location by executing the command 'Move Drill Chart' from the 'Tool' menu (Tool ➔
Drill Chart➔ Move Drill Chart). After selecting this command, click on the desired portion where you
. want to place the drill chart. The drill chart will be moved to that location. Press 'ESC' to exit the drill
chart movement operation.
Datum acts as the reference point (0,0) for the design. All measurements are taken with respect to the
datum. The co-ordinate left to the datum is taken as -ve and right to datum is taken as +ve. Also co-ordi-
nate on top of datum is +ve and bqttom one is -ve. The co-ordinates are displayed as per the co.-ordinate
system selected during the 'Netlist' file creation. If the selected system is in inches, the co-ordinate posi-
tions are shown in inches. If it is in metric, the co-ordinate system is represented in millimetres in the
layout tool (Fig. 8.62).
After fixing the datum, provide an outline to the layout by using the obstacle tool from the tool win-
dow. Select the 'Obstacle' tool from the Tool window (Tool ➔ Obstacle ➔ Select Tool) and click at the
datum to start the layout boundary. Move the cursor up till they co-ordinate reaches the desired width
of your layout (PCB width) and then move the cursor towards the right till the x co-ordinate reaches the
desired length of your layout (PCB length). Now move the cursor down from this position. Once the
cursor reaches a point which is in line with the datum, a rectangle with width and length set for your
layout is formed. Press 'ESC' key to stop the execution of' Obstacle' creation command. The boundary
for your layout (Blueprint of q'riginal PCB) is ready and you need to move all the components inside
this boundary and arrange them within that boundary and interconnect the various components as per
the connections coming from various components. For this, various 'layout tools' are required. Before
 Introduction to Embedded Systems

Layouting tools
Component footprints

. . .; ·.
•••-•-. .-., .. ,...._,..,,.,,... _ _ _ _ ,-,,,•c-,,;i..--'>.,•,;,,.""«~!-,;-.;{.C-'>..,...,_: o~.-•----JNt,:--.o,o..,_,.-=,__ tt-.:;;:ta;.;...._~~-•: .

Layouting canvas Datum

Component interconnection

( Fig. 8.61) Component Packages (footprint) placed at the layout tool

proceeding to the next steps let's have a quick glance at the important tools used from the tool window
for this. Figure 8.63 illustrates the different layout tools.
Component Tool: Selects a component. Mainly used for positioning the selected component within the
selected boundary of the layout.
Zooming Tools: Zooms in and out the selected portion of the Layout.
Obstacle Tool: Allows the drawing and editing of obstacles such as board outline, outline of compo-
nents (parts) etc.
Text Tool: Inserts texts in the selected area. It is used for placing and editing Part Number, value, notes
etc on the layout area. After selecting this tool right click on the layout window and input the required
parameters.
Online DRC: Enor checking option. If the online DRC op_ilim-is selected (ON) during the component
layout and inter-connection, any errors occuned (Package to package distance error, track to track. dis-
tance less than the set value, connection error, etc.) at the layout operation is indicated in real time.
 Embedded Hardware Design and Development

Co-ordinate Represenfation

Text Tool Edit Segment

Connect Tool Design Rule Check

ow

the
/. ~-, ..
,_ -;-: '

~~~~~::._~~~~-==::f:=:=====t====I==::'...=!_:__~--·- --····••·-
po-
Obstacle Tool Online DRC Refresh
Jtes
red Zooming Tools En-or Tool Add/Edit Route

tent fufig-:13.63) Piffe:rent layouting tools (ToolWindow)

dis-
 Introduction to Embedded Systems

Add/Edit Route Mode: Adds or edits a connection (Route)

Edit Segment Mode: Edits a selected segment of a connection (Route)
Design Rule Check (DRC): When selected, this tool checks the errors in the layout, like, missing con-
nections, wrong connections, package errors (package to package distance less than the minimum value
set), trace errors (Distance between routes less than the minimum value set), etc. Normally DRC is
performed at the end oflayouting. If the online DRC was not kept 'ON' during layouting, at the end of
layouting, you should run DRC command to verify that there are no errors in layouting the board.
Connect Tool: Inserts a new connection between any. components which is not present in the original
schematic/netlist. It is useful in situations where you need to add an extra connection apart from the
original schematic/nedist. Adding an extra connection without modifying the original netlist file will
generate DRC errors. DRC will assume it as a connection made by mistake. If you added it deliberately,
you can ignore the error.
Error Tool: Error tool gives the complete description of an error in the layout. Select the error tool and
click at the error mark on the layout window to get the corresponding error's description.
Refresh Tool: Refreshes the layout window.
There are lots of other tools also available for layout process. Describing all of them is out of the
scope of this book. Readers are requested to get the details of the rest of the tools using the 'Help'
provided byLayout Demo. tool. ·
We have already fixed· the board outline for the design using the obstacle tool. Ensure that the obsta-
cle tool created the obstacle as 'board outline', by checking the properties of the board outline rectangle.
Double clicking on the outline rectangle displays its properties window. Verify that the 'Obstacle Type'
is 'Board Outline' and 'Obstacle Layer' is 'Global Layer'. If not, set them to these values from the ap-
propriate combo box. Use 'ESC' key to exit the properties selection command. Now set the number of
layers required for your PCB. For a through hole component based board we require at least two layers
namely; 'TOP' and 'BOT (bottom) layers. The component is placed usually at 'TOP' layer and inter
connections (routes) are created at the 'BOTTOM' layer. For Surface Mount Device (SMD) components
based boards, the minimum number of layers required is one, where both component placement and
interconnection are done on the same side (layer). Depending on the complexity of interconnections and
the number of components, you can use multiple layers for routing the connections. The additional lay-
ers come in between the 'TOP' and 'BOTTOM' layers and they are referred as inner layers. Inner layers
are usually represented as 'INJ', 'IN2' etc. The number of extra layers (Inner layers) used in the layout
(PCB) solely depends on the complexity and number of inter-connections.
8:7.2.2 Layer Selection For setting the number of layers for the board, select 'layer tool' from
the Tool menu (Tool ➔ Layer➔ Select From Spreadsheet. .. ). The following spreadsheet as shown in
F1g. 8.64 pops up on the design window.
The spreadsheet _contains various information like 'Layer Name', hot key to activate the layer(' Layer
Hotkey'), 'Layer NickName', 'Layer Type' (whether the layer is used for routing or not), and Mirror
Layer (mirror the connections and components). '
Select the different layers you want to include in your PCB. You can see different layers namely
'TOP', 'BOT', 'GND', 'PWR', 'INl ', 'IN2', etc. As explained earlier, 'IN' stands for innerlayers. Our
illustrative design is a very simple board for power supply part and it does not contain any inner layers
and separate Ground and Power layers. Disable whatever layers we are not using in the design by double
clicking on the corresponding cell of 'Layer type' and set it to 'Unused'. For a double sided through hole
1
 Embedded Hardware Design and Development

Layer Layer Layer Layer Mirror

ue TOP
Name Hotkev
1
NiclcNome
TOP
Type
Raulino
Laver
BOTTOM
IS BOTTOM 2 BOT RautlnQ TOP
GND J GND None
'
of : POWER 4 PWR Unused None
• INNER1 5 IN1 Unused None
: INNER2 6 IN2 Unused None
INNER3 7 INJ Unused None
ial INNER4
INNERS
a
s
1114
IN5
Unused
Unused
None
None
. he INNER6 Ctr1 + 0 IN6 Unused None
1NNER7 Ctrl t I INT • Unused Nonel
·ill INNER& Cir! t 2 INS Unused Nonel
INNERS Clrlt 3 IN9 Unused None1
ly, • INNER10 Cb1+4 110 Unused !None
• INNER11 Clrl+ 5 111 Unused None
INNER12 Ctrl t 6 112 Unused Nonel
SMTOP Ctrl t 7 SMT Doc SMBOT
SMBOT C!rl t 8 SMB Doc SMTOP
SPTOP ClrH9 SPT Unused SPBOT
SPBOT Shift t 0 SPB Unused SPTOP
1
;!
SSTOP
SSEIOI
Shift+ 1
Shltt+Z
SST
SSB
Doc
Unused
SSBOT
SSIOP
'I ASYTOP ShltttJ AST Doc ASYBOT
he ASYBOT Shift+ 4 ASB Unused ASYTOP
ORl.DWG Shifti 5 ORO Ooc None
rp· DRILL Shiftt6 DRL Drill !None
FABDWG Shift t 7 FAB Doc None
NOTES Shlft t U NOT Doc None
ta- ·.:?c
le.
1e' ';-
·~ "

\P• ·;
of:
:rs ;_. PCB with components placed at TOP layer and routing at Bottom layer, the minim\lm layers required
are Top Layer ('TOP'), Bottom Layer ('BOT'), Solder Mask Bottom ('SMBOT'), Silk Screen Top
(SSTOP) for legend printing, Assembly Top (' ASYTOP') for giving component assembly notes, Drill
· drawing ('DRLDWG') and 'DRILL'. Keep the 'Layer Type' of all other layers to 'Unused' and close
the spreadsheet. The layers Solder mask, Silk screen, etc. are explained in a separate section of PCB
fabrication. Please refer it for more details.
8. 7.2.3 Component Placement Component placement is the process of moving components into
the layout area within the board outline and arranging them properly within the area. Components can
be placed either automatically or manually. If the automatic placement option is selected, 'Layout' au-
,m tomatically arranges the components within the area covered by the board outline. Select the Automatic
m component placement option from menu (Auto ➔ Place ➔ Board) to enable automatic placement. Auto
place option is normally used with boards with lesser number of components and interconnections. For
boards with large number of components and interconnections, the auto place option need not be an
optimised one, especially when the board size reqµ~rement; component placement, routing, etc. are criti-
cal. Manual placing is the advised method in such iituations. Manual placement involves moving of the
:ly component manually to the desired location on the layout area and placing it appropriately. To activate
lUf
manual placement, select the 'Componenficon from the tool window or 'Select Tool' from the 'Tool'
menu (Tool ➔ Component➔-select Tool). Click on the component and move itto the desired position
within the area defined by the board outline. Move all components like this. Place the components in
a way facilitating their easy interconnection. For easy interconnection, components should be oriented
 Introduction to Embedded Systems

properly. Rotate component option helps in orienting a component properly. Select the component,
right click it and select 'Rotate' option to rotate it. While placing components, give special care to place
components which are advised to be kept closer by the design guide (e.g. Placing decoupling capacitors
very close to the power supply pin of IC), placing connectors at the edge of the board, etc. The vari-
ous points to be taken care of in component placement are explained in a later section. The command
'Unplace Board' (Auto ➔ Unplace ➔ Board) removes all components which are placed within the area
bounded by the board outline.
The package of each component incorporates texts for the reference name of the component-
' Reference Designator' (Component names, Cl, C2, etc. for capacitors, Rl, R2, etc. for Resistors,
etc.) on the Assembly layer (ASYTOP) and on the Silk Screen Layer (SSTOP), 'Component Value'
(e.g. 220uF/25V - Value of capacitor Cl i_n the example) on the Assembly layer (ASYTOP), the 'Foot-
print Name' (e.g. BLKCON.I00NH/TMl SQ/W.l for connector Jl) on theAssembly layer(ASYTOP)
and the First pin indicator of the component (e.g. 1) on the Assembly layer (ASYTOP) and on the Silk
Screen Layer (SSTOP). Reference De·signator and First pin indicator are very essential for assembling
the component on the PCB. Component Value is optional since it is available from the Bill of Material
(BOM) file. 'Footprint Name' is not required. Select 'Text Tool' from Tool window and click on the
corresponding text string and move/edit/delete or rotate the text string as per the requirement. Unwanted
text is deleted and other text strings are placed close to the corresponding footprint. Use rotate option
for orienting the text strings properly. The yellow lines represent the interconnection among various
footprint pins. The interconnection is performed in the next step. Nonnally the pad corresponding to pin
number 1 of a footprint is square in appearance. The component placement for 'power_supply.mnl' net
file considered for illustration is shown in Fig. 8.65 ..

( Fig. 8.65) Component Placement, Datul'!1 and Board outline

 Embedded Hardware Design and Development

8.7.2.4 PCB Track Routing Routing deals with interconnecting the various components as per the
capture schematic diagram. The routing information is passed to the layout tool from schematic capture
through the 'Netlist' file. Routing is performed after component placement. First the components are
arranged in the desired manner. The interconnection among various components is shown in the layout
as 'Yellow lines'. The interconnection lines of a net' are· referred. as 'rats' in PCB terminology. 'Route/
track' represents the actual copper path present on the PCB. The track properties of the physical board
are determined by the 'Route' in the layout.
· Similar to component placement, routing can also be performed either automatically or manually. If
automatic routing command is executed, the sweeps are executed automatically and the complete board
. Js routed automatically. Execute the 'Autoroute' command (Auto ➔ Autoroute➔ Board) from the menu
· \for routing the board automatically. Auto routing is suitable for boards with lesser number of routes
(Interconnections). For complex routing, auto routing is comparatively inefficient and requires multiple
· layers, more layout area and route connecting holes across different layer (PTH). Manual routing is
the best choice for routing complex boards. Though it takes lots of time (of the order weeks) to route a
complex board, manual routing provides highly optimised layout with minimal number of layers and
plated through holes. Complex boards can be autorouted if the time required to complete the board is
critical and the number of layers involved as well as number of plated through holes (PTH) in the board
is not a constraint. For a double sided, 'Through hole' board, normally the components are placed at
the, 'TOP' layer and track routing is done at the bottom ('BOT') layer. If the board is a multilayer board
and the number of interconnection are very high, layout contains multiple layers (Inner layers; INl, IN2
,:etc:). In multilayer boards, apart from inner layers, there may be separate layers for ground 'GND' and
· power 'PWR'. These layers are usually spread with copper. For multilayer boards the connections are
routed through different layers and the continuation of a connection from one layer to the other layer is
achieved through a special mechanism called 'via'. Via is a drill hole connecting a route from one layer
to another route present in a different layer. Vias are copper plated or riveted to maintain electrical con-
nectivity between the two connecting routes.
While working with multilayered layouts, as routing progresses, the layout area becomes congested
with the different tracks routed on various layers. To avoid this you can selectively tum ON and OFF
different layers. Say, for example, if you are placing tracks on the second inner layer (IN2) and you feel
the routes which are already placed on the first inner layer (INl) is creating difficulties in placing the
routes on the second inner layer, you can tum off the first inner layer. Any layer can be turned off while
routing by selecting the corresponding layer from the layer selection combo box and pressing the minus
keyt '-' on the keyboard. This removes the selected layer from view. To activate the layer, press'-' key
again (Toggling with ' -'key). Layers like Assembly Layers (AST, ASB), Silk Screen Layers (SST, SSB)
can always be switched OFF till the layout process is complete. Other layers are switched ON and OFF
conveniently according to the routing process. Layer selection enabling and disabling is depicted in
Fig. 8.66.
By default the different layers of the layout are colour coded with different colours 1to distinguish
them. The default colourst for different layers are given below: ·
Global layer Yellow
Top Green
.Bottom (BOT) = Red
Inner Layer 1 (INl) = Aqua

----
t May change with change in tool version.
 Introduction to Embedded Systems

Layer Selection Combo box

Selected Layer= TOP, Layer on TOP, Layer off

Inner Layer 2 (IN2) Blue

Silk screen Top (SST) = White
Assembly Top (AST) Green
Drill Details (DRD) = Red
The colour code for different layers can be edited with the 'Colour Settings' Tool from the 'Layout
Tool'window or by executing the' Colours ... ' command (Options➔ Colours ... ) from the' Options' menu ..
Invoking the 'Colour Settings' pops up a colour selection spreadsheet. Double click on the present co-
lour for the layer in the spreadsheet and select the desired colour from the color selection window (Note:
Always perform the layout operation with the default colours provided by a layout tool for different
colours. Changing the colour of the layer is for user convenience only).
Defining Global spacing The following spacing parameters should be set before starting the rout-
ing (component interconnection) of the board.
Track-to-Track: Track-to-track spacing specifies the minimum space required between two adjacent
tracks, and between tracks and adjacent obstacles. Normally the track to track spacing is set as 12 mil
(1 mm= 39.37 mils). The track to track spacing is a critical criterion in PCB fabrication. Alwi:J,ys set a
track to track space value supported by the PCB fabricator. Nowadays PCBs with 6mil track to track
, separation is possible with latest PCB fabrication techniques.
Track-to-Via Spacing: Track-to-via spacing specifies the minimum space required between via and an
adjacent track. Normal value is 12 mils
Track-to-Pad Spacing: Specifies the minimum space required between pads (Pin pads of components)
and tracks of different nets. Normally used value is 12 mils ·
Via-to-Via Spacing: Specifies the minimum space required between two adjacent vias. Normally used
value is 12 mil
Via-to-Pad Spacing: Specifies the minimum space required between pads and adjacent vias.
Pad-to-Pad Spacing: Specifies the minimum space required between two adjacent pads.
Select the 'Global Spacing' command (Options ➔ Global Spacing ... ) from the 'Options' menu and
set the desired values for all spacing in the 'Route Spacing' spreadsheet pop-up window.
Manual routing of Board Now all pre-requisite for routing is through. To start with the routing
process, select the layer on which the routing operation is carrying out, from the layers selection combo
box. Follow the steps given below:
 Embedded Hardware Design and Development

1. Select the 'Edit Segment Mode' tool from the tools window (or execute the command
Tool ➔ Track ➔ Select Tool from the Tool menu)
2. From the View menu, choose Zoom In, click on the screen to magnify the routing area you are
working on, and then press ESC to end the zoom command
3. Select a ratsnest (A point from which the yellow line indicating an interconnection starts). The
cursor changes to a small-size crosst and the r~tsnest is attached to the pointer
. 4. Drag the pointer to draw a track on your layout area. Right clicking the left mouse button, anchors
the track at the nearest pad on the net
5. Continue to move the cursor to draw additional segments of the track, clicking the left mouse
button to create vertices (corners) in the track as you route. You can delete a routed segment by
placing the cursor over the segment and pressing DELETE key
6. Click the left mouse button to complete the route. The cursor changes to a regular-size cross and
the ratsnest disappears from the cursor
7. Select the completed route and choose Lock from the pop:.up menu. This locks the route you cre-
ated so that it cannot be moved if the board is later autorouted
8. Repeat the process for all rats of the layout. On completing a track drawing, the rat representing it
:J' is replaced with the route
ut .;j, 9. For adding a via (through hole) to connect the route (track) to a track placed on other layers, right
jt;
u. click the mouse on the desired location, while you are dragging the mouse to draw a track. Select
} :
0- ~ the 'Add Via' option
te: 10. To draw the tracks on a different layer select the layer from the layer selection combo and pro-
:nt ceed
11. To change the width of the track, right click on the track and select the 'Change Width' option.
Type the desired track width and execute. The normal value for track width is 12 mil. The mini-
mum width of track depends on the value supported by PCB faoricators and the comments from
the component manufacturer like the track width of the signal lines should be this much, etc.
Nowadays fabrication of PCBs with track width 6 mil is possible. Ensure that proper track width
is provided to tracks representing power supply lines and ground. There is a standard guideline for
track width selection for power supply lines. Follow these guidelines strictly
12. If possible reduce the track length from a component to ground and always connect the ground
tracks coming from different components in a 'star' model. This eliminates ground elevation prob-
an lems in PCB
8.7.2.5 Placement & Routing Statistics Placement and routing statistics ensures that all com-
tts)
ponents are placed in the layout and all nets are routed perfectly. It is mandatory to verify the same to
ensure that nothing is missed from the components and routes section. For verifying the placing and
routing statistics follow the steps given below.
1. Select the 'View Spreadsheet' toolbar button and choose 'Statistics'. The Statistics spreadsheet
window is displayed
2. Scroll until you find the 'Placed' and 'Routed' rows, showing the placing and routing statistics.
md The statistics should be 100% for both. A statistics value less than 100 for 'Placed' indicates some
components are missed from placing. Similarly if the statistics for 'Routed' is less than 100, the
routing is incomplete, meaning some tracks are yet to be routed
ing 3, Close the spreadsheet when you have finished viewing the statistics
abo
t Depends on the tool version in use.
 Introduction to Embedded Systems

8. 7.2. 6 Adding/Editing Texts in Layout Design

Text strings in 'Layout' is used for creating Assembly notes
and labels. To create/edit/delete a text string, select the' Text
Tool' from the Tools Menu (Tool ➔ Text➔ Select Tool from
Tool menu). Right click on the layout window for insert-
ing a new text string and select the 'new' option (or Press
'Insert' key of keyboard). The following text properties
window appears on the screen depicted in Fig. 8.67.
Adding a Text String
1. From the 'Type of Text' group box, select the type of
text that you want to create
2. Select the 'Free' option or the 'Custom Properties'
option for adding assembly note and labels. Type a
text string into the 'Text String' text box
3. Edit the 'Line Width', 'Rotation', 'Radius', 'Text
Height', 'Char Rot' (character rotation) and Char
Aspect (character aspect) text boxes as desired
4. Select the Mirrored option if you want the text to ap-
pear mirrored on the layer (useful for placing text on
the bottom of the board)
5. Select the target layer from the 'Layer dropidown list' (Ifthe text is to be printed on the silkscreen
layer, select the corresponding silkscreen layer (e.g. SST-Silkscreen Top). For assembly texts·
choose the corresponding assembly layer (e.g'. AST-Assembly Top)
6. If you want the text to be attached to a component, choose the 'Comp Attachment' button, select
the 'Attach to Component' option, input the component's reference designator (e.g. Cl, Ul, etc),
then press OK button
7. Press OK button to close the Text Edit dialog fuox
8. Position the text on the screen and click the left moµse button to place it
Moving a Text String For moving a text string,in the layout area, follow the steps given below.
1. Select the 'Text Tool' from the Tools menu
2. Click on the text, which is to be moved, with the left mouse button. Text gets attached to the
cursor
3. Move the mouse to position the text in the new location
4. Click the left mouse button to place the text
Editing a Text String Execute the following steps to edit an existing text in layout
1. Select the 'Text Tool' from the the Tools menu
2. Double click on the text which is to be edited, with the left mouse button. The 'Text Edit' window
pops-up
3. Perform the required changes on the Text Edit Dialog box and press OK
4. Press 'ESC' key to exit the text edit mode
Deleting a Text String Follow the steps given below to delete a text string.
l. Select the 'Text Tool' from Tools menu
2. Select the text by clicking on it with the left mouse button
3. Press the DELETE key
 Embedded Hardware Design and Development

8. 7.2; 7 Assembly Notes Assembly notes are useful information for those who are assembling com-
ponents on the PCB. To provide useful information, layout should contain component information like
name of the component (Cl, Rl, Dl, Ll, Ul, etc.), pin number of component, polarity of the compo-
nent, if any, point indicating the placement of an IC, etc. Some information (Like component name,
pin number, etc.) embeds with the 'Netlist' file by default and they appear on the layout at the time of
-placing the component. The assembly note information is kept on the Assembly layer (e.g. Ass~mbly
Top Layer (AST)). If the same information is present on assembly and silk screen (SST or SSB) layers,
you-cfin remove it from one of the layers. Use the 'Text Tool' from Tools menu (orTool➔ Text ➔ Select
Too\ from Tools menu) to add, delete, modify or rotate Assembly note Texts.
Apart from the text information, graphic information can also be added to the Assembly layer.
Symbols of diode, capacitor, etc. showing the polarity are typical examples. Use the obstacle tool to
create symbols on the assembly layer. For performing any operation with the assembly layer, select the
ass.embly layer (e.g. AST) from the layer selection combo box. Now select the obstacle tool and draw
whatever symbol you want (e.g. A diode symbol is created as the combination of a triangle obstacle and
three line obstacles). You can group the obstacles together by right clicking on the layout area where
the obstacles are present and moving the mouse icon in a rectangle area which contains all the obstacles
that needs to be moved together. After all obstacles of the group are selected, hold down the right button
of mouse and move the group of obstacles to the area in layout where you want to place them. Set the
'Obstacle Type' of the obstacle/obstacle group to 'Free track' by editing the obstacle/obstacle group
properties. An obstacle/obstacle group can be. linked to a component by editing the properties of the
obstacle/obstacle group (obstacles selected together). Enable Obstacle tool, right click on the obstacle/
obstacle group and select the option 'Comp Attachment ... ' from the 'Edit Obstacle' pop-up window.
Give the Reference name of the component to which the obstacle is to be linked (say Cl, Ul, etc.) on the
'Reference designator' edit box. Linking the assembly not obstacles to the component moves it along
with the component whenever the component is re-arranged in the layout window.
8.7.2.8 Drill Details To set the pad stack and drill dimensions of the vias used in the layout, execute
the steps given below.
1. Select the pin tool from the 'Tool' menu (Tool➔ Pin ➔ Select Tool)
2. Click on the via with left mouse button
3. Select 'View Spreadsheet' from Tools menu
4. Set the pad stack size and drill diameter
8.7.2.9 PCB Mounting Hole Creation Mounting holes are required for mounting the PCB on
the enclosure. PCB is fixed to the enclosure using screws and washers. PCB should contain mounting
holes and the size of the mounting· hole is determined by the mounting screws. The size of the screw is
expressed as M2, M3, etc. The 'Capture CIS' schematic tool does not contain a part for mounting holes
and we cannot add mounting hole information to schematic diagram. Mounting holes are directly added
to the layout. Follow the steps given below to add a mounting hole to the PCB layout.
1. Select the 'Component Tool' button from the toolbar
2. Right click on the layout window and select New (or Tool ➔ Component➔New ... from the 'Tool'
menu). The 'Add Component' dialog box appears on the screen
3. Select the 'Footprint' button. The 'Select Footprint dialog' box is displayed
4. In the Libraries group box, select the library 'LAYOUT. Use the Add button, if necessary, to add
this library to the list of available libraries
5. In the footprints group box, select a mounting hole (OrCAD provides three_ types of mounting
holes: MTHOLEl, MTHOLE2, and MTHOLE3)
 Introduction to Embedded Systems

6. Press OK to close the 'Select Footprint' dialog box

7. Tick the 'Non-Electric' option, and then press 'OK' to close the 'Add Component' dialog box. The
mounting hole gets attached to the cursor
8. Place the mounting hole on the desired area of your board layout by clicking the left mouse but-
ton
9. Select 'Padstack' command from the Tool menu (Tool ➔ Padstack➔ Select from Spreadsheet).
Scroll down to the "l00Rll0" section of the spreadsheet, double click on the name and select
'Non-Plated' option
Note: This feature is not available with t~e demo version of the software. Only the full featured version
supports it.
8.7.2.10 Design Rule Check(DRC) Design Rule Check (DRC) is performed to verify the layout
is meeting all design criteria and there are no errors in the layout. If online DRC is enabled, any error
in layout is automatically reported at th€ design time itself. If online DRC is ON, a white rectangle box
(DRC Box) appears on the layout window. Keep the layout area within this rectangle so that any errors
at the time of placing or routing are notified by online DRC. If the layout is not fitting in the current
DRC box, execute the following steps to incorporate the entire layout area within the board outline to
theDRCBox.
1. Select 'ZoomDRCIR,oute Box' from the View menu. The cursor shape changes to the zoom cursor
'Z'
2. Move the cursor to the target location and click the left mouse button. Layout zooms in at the new
location, centering it on the screen . ·
3. Adjust the click till the layout area fits into the DRC Box
The final :PRC check is performed by executing the 'Design Rule Check'. Executing DRC checks
the layout for all kinds of design rule errors,-missing connections and components, etc. DRC reports all
errors. The description of each error can be obtained using the error tool (Tool ➔ Error➔ Select Tool). If
there is any error in the layout process, rectify it before proceeding to the next stage (creation of gerber
files)
8. 7.2.11 Cleanup Design Cleanup design command enhances the manufacturability of the board.
Executing it automatically smoothens and checks for both aesthetic and-manufacturing problems that
might have been created ·in the process of manual or automatic routing. The design should be cleaned
up at least once, at the end of the layout process. For cleaning up the design, execute the command
'Cleanup Design' from the 'Auto' menu (Auto ➔ Cleanup Design ... ). Cleanup command corrects the
problems listed below.
• Acute angles
• Bad copper share
• Pad exits
• Overlapping vias.
8. 7.2.12 Gerber File Creation Gerber file creation is the final stage in the 'Layout' process (PCB
design process). Gerber file transforms the 'Layout' into PCB fabricating tool understandable format.
All the component info, layer info, routing info, drill info etc are included in the gerber :file. Gerber is a
universally accepted file exchange protocol between the PCB manufacturer and PCB designer.
Follow the sequence ofoperations listed below for generating gerber file corresponding to the design.
1. Save the layout file (The file is saved with extension '.max' and with the name given at the time
of creating a new design)
 Embedded Hardware Design and Development

2. Execute 'Post Process Settings' command from 'Options' menu (Options ➔ Post Process Set-
tings ... ). The 'Post Process' window appears
3. In the 'Post Process' window ensure that the 'Batch Enabled' option is set' Yes' only to the layers
which are selected during the layout design process
4. Ensure that the 'Device' option for all entry is 'EXTENTED GERBER'
5. Right click on the 'Post Process.' window and select 'Run Batch' (or execute 'Run Post Proces-
sor' from 'Auto' menu after closing the 'Post Processor' window)
6. The gerber file is generated automatically and the confirmation and path of the created file is
provided in the fonn of message boxes
Corresponding to each layer of the 'Layout', a file is created with the layer name as extension (e.g.
: •'.power_supply.top' for TOP layer). This file contains all information related to that layer. The '.tap' file
gives the drill detail information for CNC drilling. All these files (files corresponding to each layer and
· '.tap' file) are sent to the PCB manufacturer for fabricating the PCB.
8.7.2.13 Finished Layout An example of a finished layout is given in Fig. 8.68. This layout is
created for our 'power_supply.mnl' netlist example.

(pj,g. 8.68) Finished Layout

The layout contains component footprints, tracks, mounting holes, top and bottom layer, silkscreen
top layer and assembly top layer. The tracks are routed at the bottom layer and they are shown in red
colour. The white coloured text and diode symbol is assembly note and they are drawn on the assembly
top layer. Green coloured texts are labels and they are drawn on the silkscreen top layer. Save the layout
file. The file extension for layout file is '.max'. The '. max' file can be opened with the 'Layout Demo'
Tool at any time for viewing the routing/placing and modifying.
 Introduction to Embedded Systems

8.7.3 Guidelines for PCB Layout

The proper functioning of the PCB as well as its dimensions depends on the positioning of the vari-
ous components and the interconnection among them within the 'Layout' design. PCB manufacturer
fabricates the PCB as per the layout files. An inefficient layout leads to an inefficient PCB. As a rule of \·
thumb, follow the basic guidelines given below, while laying the components and interconnecting them
in the 'Layout'. ·
l. Place the components inside the layout area within the board outline, keeping the pnysical size of
the PCB in mind
2. Always keep the minimum compone11t to component distance while placing components
3. Place connectors towards the edge of the PCB and consider the enclosure thickness while placing
connectors
4. Keep the number of layers minimal. As the number of layers increases, the complexity of the
board and fabrication cost also increases and it is very difficult to debug the connections against
any non-functioning
5. Use lesser number of vias in the board. Board strength reduces with increase in number of vias.
6. Provide sufficient fixing holes on the board. Arrange fixing holes in a way providing' maximum
strength/support to the board
7. Provide appropriate track width for signal lines and power carrying lines (Refer to the design
guideline for getting the standard track width)
8. Ke~p the track to track spacing at leastthe minimum value support~d by the PCB fabricator
9. Avoid routing of signal lines over power lines. QI not it may create Electromagnetic Interference
issues)
10. Always connect ground point of different components in star model to avoid ground elevation. If
possible provide a separate ground plane (layer) and directly connect all ground connections to
this plane ,
11. Take care of components which need tO:.be kept closer (Like decoupling capacitors for ICs)
12. Avoid sharp edges for tracks .
13. Provide neat and easily understandable Asseinh!y notes
14. Avoid the congestion of routes on a layer
15. For double side component mounting, before placing a component on the bottom side of the PCB,
consider the components height and the clearance between the bottom side of PCB and the enclo-
sure when the PCB is in the mounted state

. 8~8 PRINTED _CIRCUIT ~OJtRD (P,PB) FABiijClTION

A Printed Circuit Board (PCB) is a platform for placing electronic and electro mechanical components
and interconnecting them without discrete wires. Printed Circuit Board (PCB) consists of printed con-
ductive wires (called PCB Tracks) and component layouts attached to an insulator sheet. The insulator
sheet is referred as substrate and it is usually made up of 'Glass Epoxy-A fibre glass reinforced epoxy
material' or 'Pe.rtinax-✓A phenol formaldehyde resin'. The normal thickness of this substrate sheet is
1.6 mm. PCBfs also known as Printed Wiring Board (PWB). The finished PCB layout looks exactly the
same as the Physical PCB with an· its layers representing the layers physically present in the PCB and
routes of the layout representthe tracks of the PCB. The final step in the hardware design is the fabrica-
tion of the PCB. For executing this, all information contained in the layout should be transferred to the
 Embedded Hardware Design and Development

pCB fabrication tool understandable format. The Gerber file created from the layout along with drill
details serve the purpose of transferring this information from layout to PCB fabrication tool. Gerber
1.- is a universally accepted standard for transferring relative co-ordinates and track information and com-
ponent details of a layout for PCB fabrication. Gerber files are a collection of art works. In a multilayer
PCB, each layer has its own art file representing the component co-ordinates, component info and track
n, info for that layer. The drill details file provides the drilling information (drill hole diameter, plating,
j
etc.) of different vias (PIH) present in the layout. The actual drilling is performed on the PCB using
)f i · Computer Numeric Control (CNC) drills or laser and the drilling is controlled in accordance with the
~ . drill details file.
tg 8.8. l Different Types of PCB
Depending on the complexity of connections involved and component _density, the PCB tracks may be
fouted through a single layer or multiple layers and the component placement may be either on one
side (top or bottom of PCB) and or on both sides (top and bottom of PCB). According to this, PCBs are
I· generally classified into the following categories.
m 8.B.1.1 Single Sided PCB For simple and small circuits, only one layer (either the top layer or bot-
. tom fayer) is used for routing the connections. Such PCBs are known as single sided PCBs, where all
in flie'connections and tracks are present on one side. If the components used in the design are all surface
in&unt devices (SMD), the component placement as well as the track creation is done on one side. If
s6me components are 'Through hole' components and the track routing is done only on one layer, the
'.Through hole' components should be placed on the opposite side of the PCB layer holding the tracks.
If fa. J.2 Double Sided PCB If track routing is done on both sides of the PCB and component place-
to m~nt is also done on both sides, the PCB is called as 'Double side Mounting PCB'. In 'Double side
Mounting PCB', the connection required from one side to the other side for circuit connectivity is
~S~ieved through 'Plated Through Holes (PIH)'. The PIH/via is a drilled hole which is either copper
e!~ctroplated or riveted with small rivets. The via may be a visible via with a cylindrical hole and plating
on both PCB sides or a completely buried via in which the drill hole is totally filled with conductive ma-
terial like copper. It is advised to use less via as possible in a board and use buried via, in case of any via
required. The major issue in using buried via is fabrication cost. In a~cient times the circuit connection
between two end points of a drill hole was achieved through inserting a conductive wire and soldering
the ends of the wire to the circuit on the pads present on both sides of the board.
8.8.1. 3 Multilayer PCB If the complexity of connections in the circuit to be fabricated is •high,
routing of connections is performed using multiple layers. Multiple layered PCBs, contain additional
routing layers called 'inner layers' apart from the top and bottom layers. The number of layers required
ts and the connections on each layer is fixed at the routing time itself and each layer in the layout repre-
n- sents a physical layer in the PCB. The number of inner layers may vary from 1 to 16 ·depending on the
or circuit complexity. It is a common practice to allocate separate layers for 'Ground' and 'Power Supply'
(Y in multilayer PCBs. The separafe ground layer and power layer reduces the effect of any accidental an-
is tenp.a loop formation in the circuit All layers of the PCB are fabricated separately and finally they are
stacked and glued together. Alignment marks are provided on each layer for aligning the layers properly
for stacking them. The final PCB looks like a single PCB, though it contains PCB layers inside. The re-
a- quired interconnections between t4e tracks of different internal layers are established through drill holes
1e called 'via'. The 'via' may be a copper electroplated drill hole or a riveted 'Plated Through Hole'.
:1
!

Introduction to Embedded Systems

8.8.1.4 Piggy-Back/Plug-in/Daughter PCB Piggy-backJplug-in/daughter PCBs are designed to

plug into some other PCBs. The Piggy-back PCB may itself be a single sided/double side mounting or
multilayer PCB. Most of the COTS component comes as piggy-backJplug-in PCBs.
8.8.1.5 Flexible PCB Flexible PCBs are highly flexible compared to normal PCBs. Normal PCBs
use rigid substrate for copper etching platform and they are 'rigid' in nature, whereas flexible PCBs use
:flexible substrates like plastic as the substrate sheet and the copper film are deposited on top of it: Flex-
ible PCBs are widely used in fabricating 'Antennas' for RF systems and applications requiring connec-
tors as a flexible PCB, like membrane keypad connectors LCD connectors, etc.

8.8.2 PCB Fabrication Methods

PCB fabrication is the process of creating physical PCB from the layout files supplied in the form of
gerber files and drill detail files. Three common techniques are adopted for this. They are described in
detail in the following sections.
8. 8.2.1 Photo Engraving (PCB Etching) Photo engraving is the oldest technology used in PCB
fabrication. It is the most popular technology and even today also it plays a vital role in PCB fabrication.
Photo engraving is based on the photographic technique (Technique similar to the one used in develop-
ing photographs from a negative film) and it makes use of photo _masks and chemical etching. To adopt
photo engraving technique, the different layers of the layout should be converted into a film very similar
to the negatives of photograph. The gerber photo plotter files are inputted to a photo plotting machine
and it produces the photo-plot (PCB film) of each layer. The process of creation of PCB film from art
files is termed as 'Photo plotting'. The tracks and copper using areas in the layer are opaque (black) and
other portions are transparent in the films. These PCB films are used as 'Photo mask' for photo engrav~
mg.
Copper coated on a substrate sheet is used as the metal for photo engraving. A photo sensitive mate- .
rial called 'photo· resist', which is resistant to acids and other etching materials is applied to the copper
sheet. The 'photo mask (PCB film for the corresponding layer)' is kept on top of the photo resist mate-
rial coated copper sheet and it is aligned properly. This sheet is then exposed to strong ultraviolet rays.
The places on the target copper clad board where the PCB film is transparent gets hardened and the
opaque regions remain as such. The photo resist is then developed by washing in a solvent that removes
the unhardened parts. Finally, the copper area to be engraved (removed) is exposed to an acid or other
etching compound which dissolves the exposed parts of the copper sheet. Ferric chloride or ammonium
per sulphate chemical bath is used for removing the unwanted copper from the substrate. Each layer of
the PCB is fabricated like this and then the required vias are drilled on each layer. Finally all layers are
stacked together exactly as present in the layout design to form the finished PCB. Vias used for inter-
connecting various layers are copper plated or a conductive rivet is inserted into them to establish circuit
connections.
8.8.2.2 PCB Milling PCB milling is a straightforward and more precise technique for fabricating
PCBs. It uses 2 or 3 axial milling machine to mill away the unwanted copptrr from a copper cladded f
substrate which is used for each layer. The milling is done on the basis of gerber file for each layer. Here J'.
1
no PCB films are created and it is a chemical free process. PCB milling machine operates in a way simi-
lar to a photo plotter and receives the commands from the host software that controls the position of the e
milling head in the x and y axes (for 2 axial milling) and x, y and z axes (for 3 axial milling). Compared t
to photo engraving, the accuracy of PCB milling is very high. PCB milling accuracy is dependent only
 Embedded Hardware Design and Development

'
on milling system accuracy and the milling bits. With milling technique it is very easy to create sharp
to
or track edges, pads, etc. on the PCB. Both milling process and engraving process are 'subtractive' process
since copper is removed from the substrate board to create electrical isolation.

Bs B.8.2.3 PCB Printing PCB printing is the latest technology adopted in PCB fabrication. As the
1se name indicates PCB printing is similar to the ordinary printing. The only difference is that instead of ink
and toner, conductive ink is used and papers are replaced by substrates. Also special types of printers
ec-
ate used for the same. ·

8'.8.3 How a finished PCB looks like and how it is made operational
. As mentioned earlier, all the layers of the 'Layout file' are transformed into corresponding physical
l of layer using any of the above-mentioned fabrication techniques and after fabrication of all layers, they
iin ares.tacked and glued together in the same order as they present in the 'Layout file'. The conductive drill
holes are plated with copper, or riveted using appropriate rivets. Now the top layer and bottom layer are
the only visible layers and they contain the top layer and bottom layer tracks (if any) and component
CB placement copper spread pads (for Surface Mount Devices) and through hole pads (for through hole
10n. · ~omponents). If you examine this PCB you can see the tracks and component layouts but you may not
.op- be able to identify which component layout is corresponding to a component given in the 'schematic
lopt · diagram', since there is no visual indication marks provided on the PCB at this stage, describing the
1ilar t~mponent name, its value (if needed) and the. component polarity if any (for polar components like
une capacitors). Next step is the. printing of component 'Part reference Number' details on the top/bottom
l art layer where component layout is done. ·
and
rav- · 8.8,3.1 Solder Mask One more step is involved in the PCB fabrication process before printing
the part reference text and layout outlines. In the etched/milled or printed PCB the copper tracks are
1ate- exposed and there is a chance for corrosion and abrasion. To avoid this, a plastic layer is deposited on
pper top of the PCB. This plastic layer is known as 'Solder Mask'. Solder mask protects all the copper track
tate- and spreading from exposure to the surrounding atmosphere. Solder mask also resists the "bead-up" of
:ays. solder (wetting by solder; where solder is a conductive lead material for fixing components to the pad
I the ·• and track) and prevents the solder used for fixing components from :flowing in the PCB. Solder mask
oves is exposed in points which are intended for soldering components. The commonly used solder mask is
)ther green coloured and that's why PCBs are green coloured in appearance. Solder mask is applied to top and
1ium 1
bottom layers of PCB depend~ng on the presence of copper components. Solder masks are also available
er of in other colours like red, black, blue, etc.
s are 8.8.3.2 Silk Screen The p·rocess of printing the part reference information for various components
nter· on top of the solder mask layer is called 'Silk Screen printing or Legend printing' and the printings are
,rcuit referred to 'Silk Screen legend'. This legend provides readable information on component part numbers
and placement of components like where the first pin should come, or the polarity information like +
ating and - of components and also the layout boundaries of the components. This information is necessary
.dded: for placing the components while assembling the· components on the PCB and also for repairing. The
Here.· printing is performed using 'Silk screens'. It can also be done using Inkjet printersJSilk screen printing
simi- is done on top and/or bottom layer of the PCB depending on the placement of components on these lay-
Jf the . ers. The silk screen layout file corresponding to the top layer is 'Silk Screen Top (SST)' and for bottom
pared ' layer it is 'Silk Screen Bottom (SSB)'.
tonly
 Introduction to Embedded Systems

8.8.3.3 Testing PCB The PCB manufacturer itself conducts a preliminary test, after fabricating the
PCB to ensure that all the nets (connections) in the gerber file supplied by the end user got interconnect-
ed according to the gerber files: This test is known as "Bare Board Test (BBT)". BBT is conducted at the
manufacturing setup and the PCB is delivered to the end user only after ensuring the BBT is cqtrect.
Checking the internal connections within a multilayered board is very difficult. However the end user
can conduct tests like "Visual Inspection", on receiving the PCB. "Visual Inspection" is performed to
ensure there are no 'shorts·' within the visible part of the PCB. A magnifying glass is used for examining
the board. It is advised to perform a Visual Inspection test always, before soldering the components.
Nowadays tests like JTAG Boundary scanning is available for testing the interconnection among vari-
ous ICs present in the board using the boundary scan cells of the ICs and JTAG interface.
8.8.3.4 Component Assembly Component assembly is the process of soldering the circuit com-
ponents like capacitors, resistors, ICs, connectors, etc. on the PCB. The components are connected to
the PCB through soldering. The soldering technique may be either manual or automated. In manual
soldering process, components are soldered on the board by soldering experts using soldering iron and
soldering lead. The Bill of Materials generated for the schematic diagram is used as the reference part
number and value selector for the components and the legend printed on the PCB helps in finding out
which component is to be placed on which part of the PCB. In automated soldering process, machines
are used for executing the soldering operation. Here also human intervention is required. Various solder-
ing techniques like re-flow soldering, etc. are used. Techniques like X-ray are used for inspecting the
correctness of machine soldering in lead free component assemblies.
It is not recommended to assemqle all components in a single stretch for the first time in a proto mod-
el development. Split the circuit into different modules like power supply module, processor module,
etc. and assemble the components for one module at a time preferably starting with the power supply
part of the board and ensure that each module is working properly. Examine the expected output of each
module and ensure you are getting the correct output. Move on to the next modules only after getting the
correct output from the last assembled module. If you are not getting the expected output, ensure that all
components necessary for the functioning of that module is assembled properly, examine the input and
output signals of the modules using hardware debugging tools like Multimeter, CRO, Logic Analyser,
etc. Make necessary changes in the PCB circuits i(.required. Most of the times adding of additional
components, cutting ?f tracks, etc, may be required in the first board since we are using it for the first
time and we are not familiar with the component and system behaviour in it. Hence this board will be an
experimenting board-More precisely ''Prototype Board" in embedded technical term. The drawbacks of
the circuits in the proto board and the circuit and component modifications, required if any, are included
in the next versions of the proto board and it goes into commercial production once it functions in the
expected way. It is strongly advised to fabricate lesser number of PCBs in the first run.
Run small test applications on the processor part to ensure that the processor part is working properly.
For example, if the board contains some LEDs or buzzers connected to the output ports of the processor,
you can write small firmware program to manipulate their status (like blinking LED, turning buzzer ON
and OFF, etc.). This helps in ensuring the processor part is functioning properly. You may find it very
difficult to do a-modulewise assembling and testing, but remember it is a one~time process and once
you identify the problems with a board you can apply the remedial measures to all boards and go for a
mass assembly. The proverb "A stitch in time saves nine" is. really meaningful in the case of embedded
hardware design. If you spend some effort for this it will definitely help you in saving the additional
time, effort and money in debugging.
 Embedded Hardware Design and Development

Le If you assemble all the components together i~ a si~gle stretch for the fir~\time and power it ()N,
t- you can see your product functioning properly only\f you are a very lutky person ©, Otherwise it may
Le end up in a board blast or damage. Moreover you won't learn anything on the hardwan¼nd the mystery
behind how it functions, if it starts functioning in the first run itself. Debugging the hardware only gives
you sufficient knowledge on it (from a developer perspective). From a product development company
perspective, the product should function fully in,the fir~t runjtself. The design is always well checked,
simulated and debugged before fabrication to avoid all possible piob'1ems. Still t&re m~y be chances for
pr9blems, since hardware functioning is unpredictable.

Solder Mask
Component Soldered on Footprint
(Green Coloured) Silk Screen Legend

t
1
lrt

,,,
,d- ,)

Plated Through Hole

.er, PCB Fixing Hole (PTH)
aal
rst
an (ftg; 8.69) Finished PCB with components Assembled (Top view)
Courtesy of Keil (www.keil.com) ·
. of

~~~ I 8.8.3.S Conformal Coating The embedded product need not be deployed in a controlled envi- .
ronment always. Hence the PCB along with the components assembled on it should withstand all the
rly. extreme operating conditions. The environment where the PCB is going to deploy may be a dusty one,
;or, highly humid one, etc. Presence of metal dust particles and conducting corroding particles may create
)N electrical short-circuiting or corroding of the PCB. A special coating called 'Conformal coating' is ap-
ery .· plied over the PCB to prevent this. Conformal coating should only be applied after assembling all the
t1ce components. Dilute solution of silicon rubber or epoxy is used as the conformal coating material. The
>r a assembled PCB is either dipped in the conformal solution or the conformal solution is sprayed on the
ied assembled PCB. Another technique used for conformal coating is sputtering of plastic on to the PCB
,nal in a vacuum chamber. The major disadvantage of using a conformal coating i~, servicing of the board
and replacement of the components, in case of any damage, is extremely diffi~ult, since the coating is
a permanent one.
 Introduction to Embedded Systems

✓ The hardware of embedded system contains analog electronic components like resistors, capacitors, inductors,
OpAmps, diodes, transistors, MOSFETs, etc., Digital electronic components like logic gates, buffers, encoders
and decoders, multiplexers and de-multiplexers, latches, etc. and digital sequential and combinational circuits,
Ahalog, digital and rnixed Integrated Circuits (ICs) and Printed Circuit Board -· .
✓ Open collector is a special transistor configuration for interfacing the ougmt signals from Integrated Circuits with·.
other systems which operate at the sarrte or different voltage level that of the IC as
✓ A digital circuit used in embedded hardware design_ can be a Combfriational or a Seque,ntial,circuit. The outpµtof -
a combinationalcircuit is dependent only on the present input, whereas the output.of a sequer1tial circuit d~pen.ds ·_·.
on both present and past inP,uts . _.
✓ An Integrated Circuit (IC) is a miniaturised form of an electronics circuit built on the surface of a thin silicon \XI~.',
fer. VLSI design deats with the design ofICs. VHD~_i§'ah~,tJhV~~ <i~sc,ription lang1;1~~e~se~ in,;\/LSI desi~ _\.
✓ Electronic De:signAutomation (EPA) too_l is aset.of C?niputc:r,Aideq pesigµ I M!lilitflwt\llingi(CAD/CAJyl) -.
#i
s~ftware packages \Vhich heip destgni11g.and'.mjnufacturi11gJhe.~rectrq~ic' hatdwire' likfintegrated circuf(s;
printed circuit b~aid, etc. · ._-.·_ _.. ,. · .·. · ,.· ·..·.·. . . . ·• ·· · · · · ,, ·· · · ..
✓ OrCAD is.a p~piilaf?D,:\to~IforB{~B ;dq~i~n fl;q,m:p~.cie11s\;, .~ sx~te~sJ~cadence.com~. Capturei;rs
is the 0i:CADfo'o)
.,' . .
for'circllltCreatibn
· .<·"°_.'.'/ '. ", __ . .
(s6hi:inatlc2aptunti!t),
'">i-~,- ,, :. ,,/:, :,• ., _,,,
1_~,-""'; • ,;"
. ,9:;1t
c,ft .. ,,".'•,;, •. ,.,.·
is the PGf3'~<!,YOUt tool and pSPICE is the''
. ~-''

circuit simul otJJ , ~- ,

✓ The schem~tic/~ap~Wg tqol~6nvirtitliei2m~X?~;~f:. '. '. J,:;Ap1he inte~conn~cti9n;tmorfg them in an eles~,
tronic circuJ~tq; ,:.,::. 2,.;.,·r~pfeS~gf~tt9~,c~llett~~fli.it/·S ~/:, '.. .. · · · ·. : . ;" .. _· · . ·.·. _ ·.· '
✓ Packages are {t ,· '.cfa,'t<;t,enfities"'fo[describirig'~ io1I1pon¢tihti PQB design.'PDW, iIP, SOIC, TSSOP, VQFP,
PQFP are exajpiis'forsta119ardpa,c~ges.: ~;. : :/,·" _ ·. _ -_. :, _ - _ •·· . . .-_· _·. · ·. .
✓ Netlist-:file coritai~s)nfo~afitin~bb4ftije:p~cfag~tfor'4ifferent components of the circuit diagram, and the
interconnection among thediffyf~ntcqmponents·represen:tedin theJormof:NET's :
✓ The multiple planes used fgr:int~rc61lll~ctit1g ;different cginpon~.µts ,in a PCB is known ·as 'Layers' and the inter-
connection among various components is referred is 'Routes' PCB tenninology in ,
✓ The layout tool generates a blueprint of the actual PCB in terms of the different component placement, the in-
terconnection among them. The layout information is passed to the PCB fabricator in a universally acceptable
standard called gerber file for fabricating the PCB. Gerber file is a collection of art files corresponding to the
different layers of the PCB and drill details for the vias and holes present on the PCB
✓ PCB is a platform for placing electronic and electromechanical components and interconnecting them without
discrete wires. PCB contains printed conductive wires (called PCB tracks) and component layouts attached to
an insulator sheet. The insulator sheet is refen-ed as substrate and it is usually made up of 'Glass Epoxy-A fibre
glass reinforced epoxy material' or 'Pertinax-~A phenol fonnaldehyde resin'. The normal thickness of this sub-
strate sheet is 1.6 mm
✓ PCB etching (Photo engraving), PCB milling and PCB printing are the commonly used PCB fabrication tech-
niques to develop a PCB from the gerber file information
✓ PCBs can be classified into Single Sided PCB, Double Sided PCB, Multilayer PCB, etc., based on the number of
layers and component placement

Open Collector An NPN transistor configuration with emitter connected to ground and collector
left unconnected. It is an I/0 interface standard in electronic circuits
 Embedded Hardware Design and Development

Analog/Digital Circuit which produces the output as the output corresponding to

the logical operation performed on the input signals
Logic circuit for ·increasing the driving capability of a logic circuit in digital
electronic circuits
.Logic circuit for latching data: in digital circuits
• ·Logic.circuit for generating all the possible c9mbinations of the input signals in
.. digital circuit
Logiccircuiffor encodirigthelnput signals to a particular output format
~: >~Lcigic .cifouit\ylrich~'ac~s•~~ a switch,whi6h.c0Illieyts·t1nei~put1irie fro~' a
ii\'jnpriflines;to, 'an ;*tput11irteita giveirpoint ol time ·: : .• . . :r,:,
~Mul#piexer \Ugic'tircuii which perform~ the reverse operation bTinultipl~Xer ...· .. .·,. ·•. i ...·
,m~irif.ti6.~;i Circuit. · ... A digit~l circ11itihich i~ a combi11atio'I1 of logic gate;_:The butput of th¢. c6aj{:
' ·~4iatfonal ~frcuit '¥a,gi~¢A p9int afttiµe <{r
·is d~pehd~nfonly on the state thi'.
~\ ;\,C.,~nJ)lltS at the giy~n pbitlt pf time •· . •,. _· . . .. .! • ·..• ,
;-,.
t~~que,rn,1qt~~it\,;·''.
~,-, ,
· ·i;: A,ciigit~l l9gi9c_ircµit 'Y.hose 911tpµta,ta1;y given ppintpftfrrie µepends oll.~tf
.· ·.th~ presenta,ndpastil{puts ·.. ·.. , · ·· .. ' . ·. ' ·• .... , .• . ·. · . <.:
A.Illbiaturi~~d impltll}entation of an electronic~ ,circuit containing transistJrs
, and ~th.er passiv~ el~ctr◊9ic cqmp~nents in a silico~·wafer · · ·
Kl.design
·AHardware I)escriptionLanguage for VLSI design
.A set of Computer Aided Design /cManufacturiilg (CAD/CAM) soft\.vare
/ages which helps in designing and .manufacturing the,.electr6nic. bardware
:<A popular EDA tool for PCB de~ign from'. Cad~nce'riesfgil.Syste~s ,.
An''etitity representin~ the physical characteristics (length, width, number 9f .
pins, type of piris (surface mount6'ithr6lfgh hoie), pin'.size,' etc.) of a hardw~re •.
component (like IC, capacitor, etc.) irf electronic circuit
::,Netlist .file A soft· form representatior1 of the_ package. of compo:nents and the interconn~c-
tio!]. among the components in an 'electronic circuit
Footprint A pictorial representation of a component when it is looked from the top (top
view of a component)
Routes The interconnection amQng the pins/leads of various components in a PCB
Layers The 'Multiple planes' for performing the routing operation, if the number of
interconnections in a design is high in a PCB
Vias : :. The cond~ctive drill holes for providing electrical connectivity among varioµs
· · layers in a 'Multilayer' PCB
Gerber File • A universilly acceptable standard for representing layout information for PCB
fabrication
Printed Circuit Board (PCB) A platfom1 for placing electronic and electromechanical components and inter-
f
connecting them without discrete wires.
· PCB Etching (Photo engraving) : A subtractive method for fabricating the PCB
PCB Milling A subtractive method for fabricating the PCB
.PCB Printing An additive method for fabricating the PCB
'Single Sided PCB PCB with a single layer for routing and connections
;:}Jouble Sided PCB PCB with track routing and component placement done on both sides of the
,r · PCB
 Introduction to Embedded Systems

> ,

'Mutiifa · ··. · ·.- ,., ~f~~~p\!lffig

:':·f.:2; '.'.'.'.:. ?,t-);.r
/Big~-h PGBs

~~~

Objective Questions
l. Which of the following analog electronic component is used for clamp'ing of voltage in·electronic circuits
(a) Schottky diode (b) Transistor (c) TRIAC (d) Zener diode
2. Which of the following analog electronic component(s) is (are) used for noise signal filtering in electronic
circuits
(a) Capacitor (b) Transistor (c) Inductor (d) All of these
(e) Only (a) and (c)
3. Which of the following is (are) true about Open Collector configuration?
(a) The emitter of the transistor is grounded (b) The emitter of the transistor is open
(c) The collector of the transistor is open . (d) The collector of the _transistor is grounded ·
oow~~ oo~~w
4. The logic expression Y = AB + AB represents the logic gate
(a) AND (b) NAND (c) OR (d) XOR
(e) NOR
5. Which of the following is-.an example for Buffer IC?
(a) 74LS00 (b) 74LS244 (c) 74LS08 (d) 74LS373
(e) None of these
6. Which of the following digital circuits is used for selecting one input from a set of inputs and connecting it to an
output line
(a) Buffer (b) Latch (c) Multiplexer (d) 'De-Multiplexer
(e) None of these
7. Combinational circuits contain a memory element. State True or False
(a) True (b) False
8. Half Adder is an example of Sequential circuit. State True or False
(a) True (b) False
9. Which of the following flip-flop is known as Delay Flip-Flop
(a) S-R (b) J-K (c) D (d) T
10. For an S-R flip-flop, the previous output state is 0 and the current input state is S = R = 1, what is the current output
state?
(a) 1 (b) 0 (c) Undefined
11. Which of the following flip-flop is known as Toggle Flip-Flop
(a) S-R (b) J-K (c) D (d) T
12. For a J-K Flip-Flop, the previous output state is 1 and the current input state is J = K =0, what is the current output
state?
(a) 1 (b) 0 (c) Undefined-
 Embedded Hardware Design and Development

13. For a J-K Flip-Flop, the previous output state is O and the current input state is J=K=l, what is the current output
state?
(a) 1 (b) 0 (c) Undefined
14. For a T Flip-Flop, the previous output state is l and the current input state is l, what will be the current output state
on applying a clock pulse?
(a) I (b) 0 (c) Undefined
i5. The number of logic gates present in an IC is 500. The integration type of the IC is?
(a) MSI (b) SSI (c) LSI (d) VLSI
16. The type of integration for a microprocessor chip is
. (a) MSI (b).,SSI (c) LSI (d) VLSI
17. The design of an integrated circuit with built-in ADC is an example for
(a) Analog (b) Digital (c) Mixed signal (d) None of these
18. In embedded hardware design context, schematic represents
(a) The physical arrangement of various components present in the hardware product
(b) The different components involved in a hardware product and the interconnection among them
(c) Both of these (d) None of these
19. In embedged hardware design context, Bill of Materials (BoM) represents
(a) The type and value of each compon~nts present in the hardware
(b) The quantity of different components present in the hardware
(c) Both of these (d) None of these
20. In embedded hardware design context, 'Netlist' is
(a) The soft form representation of the different components of a hardware and the interconnection among them
(b) The output file generated from schematic design (c) The input file for the PCB layout design
(d) All of these (e) None of these
21. In embedded hardware design context, 'Layout' is
(al_!. soft form representation of the P~B
(b) Software 'Blueprint' representing the physical placement of components in a hardware
(c) All of these (d) None of these
- 22. Which of the following are the building blocks of a 'layout'?_
(a) Footpr~nts (b) Routes (c) Layers (d) Vias
(e) Allofthese (f) (a)and(b)
23. What is 'Footprint' in the 'I:ayout' context?
(a) The 'Top view' of a component
(b) The three-dimensional representation of a component
(c) Both of these (d) None of these
24. Which of the following package(s) contain pins/pads on only one side of the component?
(a) Zigzag In-line Package (ZIP) (b) Single In-line Package (SIP)
(c) Dual In-line Package (DIP) . (d) All of these (e) None of these
25. Which of the following is a Surface Mount Package?
(a) PDIP (b) TSSOP (c) SOIC (d) All of these
(e) only (b) and (c)
ut 26. Which of the following package(s) contain(s) pins/pads on the four sides of the component?
(a) VQFP (b) SOICS (c) TSSOP (d) PQFP
(e) (a) and (d)
27. The representation of interconnection among vadous components of a hardware in 'Layout' is known as
(a) Footprint (b) Route/Trace (c) Layer (d) None of these
ut 28. In embedded hardware design context, a 'via' is a
(a) conductive drill hole (b) interconnection among t"Yo components (c) Ground line
(d) Power line (e) None of these
 Introduction to Embedded Systems

29. Which is (are) the layers of 'Layout' used for printing 'Assembly Notes'?
(a) AST (b) ASB (c) TOP (d) BOT
(e) (a) and (b)
30. What is gerber file in the PCB Design context?
(a) File containing the component PCB layout info, routing info, drill details, etc. in a universally accepted file
exchange protocol format
(b) File containing the co.mponentPCB layout info, routing info, drill details, etc. in a proprietary file exchange
protocol format
(c) A collection of art works ~n a gerber f9rmat for each layer of the PCB
(d) (a) and (c) (e) None ~fthese
31. Which of the following is(are) true about a single sided PCB?
(a) Only a single layer is used for routing t):ie connections between components
(b) Components are placed on ohly one side of the PCB
(c) All of these (d) None of these
32. Which of the following is(are) true about flexible PCB?
(a) Highly flexible compared to normal PCB (b) Uses flexible substrate for etching
(c) Commonly used for the fabrication of Antennas,membrane keyboards, etc.
(d) All of these (e) None of these
33. Which of the following technique(s) is(are) used for PCB fabrication
(a) Photo Engraving (b) PCB Milling (c) PCB printing (d) All of these
34. Which of the following is(are) subtractive process for PCB fabrication?
(a) Photo Engraving · (b) PCB printing (c) PCB Milling (d) All of these
(e) None of these (t) only (a) and (c)
35. Which of the following is(are) true ab·out 'Solder Mask'?·
(a) It is a conductive layer (b) It is a non-conductive layer
(c) It protects the copper tracks from corrosion (d) It prevents the 'wetting' of solder
(e) (b), (c) and (d)
36. Which of the following is(are) true about 'Conformal Coating'?
(a) It is a conductive layer (b) It is a non-conductive layer
(c) It is a coating over the PCB to protect PCB
(d) Dilute solution of silicon rubber or epoxy, or plastic is used as the conformal coating material
(e) (b),(c)and(d)

Review Questions
1. E:tplain the role of the analog electronic components resistor, transistor, capacitor and diode in embedded hard-
ware design. Draw a circuit used in embedded application using these components
2. Explain the role of logic gates in embedded hardware design. Draw a circuit using the 'AND' and 'OR' gate ICs
in embedded application
3. What is open collector? State its significance in embedded hardware development
4. Explain the role of de-coders in embedded hardware development. Draw the circuit diagram for interfacing a 3-bit
binary decoder with 8051. Explain the functioning of the circuit
/
5. What is a combinational circuit? Draw a combinational circuit for embedded application development !

6. What is a ~equential circuit? Draw a sequential circuitand expl!lin its functioning

7. Expla1n the difference between digital combinationaVand sequential circuits
', \ I

8. Explain tq_e difference between synchronous and asynchronous sequential circuits. Give an example for both
9. What is an Integrated Circuit (IC)? Explain the different typ,e~ of integrations for ICs. Give an example for each
 Bmbedded Hardware Design and Development

1O. Explain the different types of IC design. Give an example for each
11. Explain the different steps involved in VHDL based IC design
12. · What is Electronic Design Automation (EDA) tool. Explain the role of EDA tools in embedded system design
13. What is schematic? Explain the role of schematic in embedded hardware design
14. Explain 'Bill of Material' (BoM) in embedded hardware design context. What is the use of BoM in Embedded
Hardware design and development?
15. What is 'Netlist' in the Embedded Hardware design context? Explain its role in hardware design
16. · Explain the terms 'Layout' and 'Layout Design' in the hardware design context
17. What are the building blocks of a 'Layout'? Explain them in detail
18. What is the difference between 'Package' and 'Footprint'? Explain the significance of both in embedded hardware
design .
19. What is 'Package' in the embedded hardware design context? What is 'Through hole' package and 'Surface Mount'
package?
20. What is the difference between 'Single In-line Package' (SIP) and 'Dual In-line Package' (DIP)?
21. What are the commonly available DIP packages?
22. What is 'Zigzag In-line Package' (ZIP)?
23. Explain the commonly used 'Surface Mount Packages' in detail
24. What is 'layer' in the embedded hardware design context?
25. What is 'via'? What-is the difference between 'via' and 'Through hole'?
26. What is 'Through hole'? What are the different types of' Through holes' used in PCB design?
27. What is 'Assembly Note'? What is the role of 'Assembly Notes' in embedded hardware design?
28. What is 'gerber'? What is 'gerber file' in PCB design context?
29. Explain the general guidelines for an efficient PCB layout
30. Explain PCB in the Hardware Design context? Explain the different types of PCBs
31. What is 'Flexible PCB'? What is its role in Embedded ·systems?
32. Explain the different PCB fabricatio1:1 techniques. State the merits and drawbacks of each
33. Explain the 'PCB etching' process in detail
34. What is 'Solder Mask'? Explain its significance in PCB fabrication
35. What is 'Silk Screen' and 'Silk Screen Printing'? Explain their significance in PCB fabrication
36. What is 'Conformal Coating' in the PCB context? Explain its significance in hardware maintenance.

Lab Assignments
·Draw the schematic diagram using CaptureCIS for enc'odrµg the keys colll'le~ted tolhe input lines of the 8 to 3
encoder 74LS148 arid reading the encoded output usingtlie AT89C51' microcontroller as per the requirements.
I- give:tfbelow ·· .
(a) The Enable Input (EI) line of the encoder is permanently grounded
.(b) .The
.·
output lines AO
.
to A2 of'• t~e encoder
. . .
are
. .
interfac~d
. .
to Pl. 0 to P1.2. of
. ' the microcontroller
· r(c) Assume that a regulated supply'c,f 5Vis fodto 'the board from an externat,ac-dcadaptor. Use apower jack
"•• •. ,•

: gn the )Joard for connectµig the external supp ly:'Us.e filfe;.capacifor O.1 MFD/12V along with the jack
it /(g) jys~ a~iystitlfrequ~liiy oq 2N{Hzfor themicrocoiitroller .· · ... . . ·· . · _- . _
/ ;:i~~J§~J~~:~P~:iay~ut'torthe a6Bve.re~uJeni,entusing 'brout'tool. The_package·detailsfor the components
I
,g1~e,ebel?w,~ .···.. .:. . , ·, , • .. . ' , -. . . ·. . ·. •· •. ·. •. ·
ipfocbntrolletifPIP 40,74LS148 :.PDIP 16, Capacitor: Use a 2 Pin Package from the design Library, Crystal
lJs1hli€ tbi6'tigli'iib1e pacl<lige (or 2 Pin package) for ~tystaLfrom the Lay~ufdesigft·library, Pow~r Jack : Use
pJ>Wer ja9k package•from theJibrary · .
 Introduction to Embedded Systems

3. Draw the schematic diagram using CaptureCIS to interface the 3_ to 8 decode.r 74LS138 with the AT89CS1 mi-
crocontroller as per the requirements given below
(a) LEDs are connected to the 8 output lines of the decoder in such a way that anode is connected to SV supply
and cathode to the output pin of the decoder .'
(b) The enable lines El\ and E2\ are grounded pennanently and E3 is connected to the supply voltage VCC
through a high value current limiting resistor
(c) The input lines AO, Al and A2 of the.microcontroller are connected io the Port/ pins,Pl.0 Jo Pl.2 qf.Jhe
microcontroller . . .
(d) Assume that a regulated supply of 5V _is fed to the board frorD:in,extern~l ac~dc adaptor. Use a po~er jack
on the boitrd for connecting the external supply. Usdilter capacitor 0.1MFD/12V c.t.long with thej~~k>>, · '
(e) U~e a crystalJr~quency 002MHz for the 1;11icroqmti;oller , .• . .· . ,
4. Deve_lo~ the PCB layout for the above requirement using 'Layouf tool. The pickage details for the cg~p9n~
are given below , .. , . . , . ·::-2:,, •
Microcontroller: PDIP 40, 74LS138: .PDIP 16, Capacitor: Use a) Pin. Packagefrom ti).e design library, Crys{al ·
: Use the through hole package (or 2 Pin pa~kage) for crystal fro~ t]:ieLayo11f:designJibrary, Power Jack : Use
the power jack package from the library · , ·· · · ·· , ' . • _'
5. Draw the schematic diagram using CaptureCIS for:interfacing the Tri-State. Buffer 74LS244 in rpemory mapped
configuration with AT89C5 l microcoµtr,ollerns:per the requirements gi'{~W below · ·
(a) DIP switche~ are connected to.the 8 input lines of the tri~state buffer thro~gh resistors 4.7K. The input lh-te ·
is at logic high when the S\_Yitch isatopen state and at logiclow,wh~n.theswitch.isatdosed state
(b) The output lines of the buffer are connected to.the data _!:!us p<;>Ji.PP ~[the micrq9ontro1ler
(c) Tne Port 0 pins are pulled to the supply voltage throughf7KJesistor . .
(d) The address for the tri-state buffer is assigned as OPFSH. Use logic gates AND, NAND and 3 to 8 decode~
IC to decode the address line and generate the ad~ress selection pulse for the buffer · , · · .· '
(e) The address selection pulse along with the RD\ signal of tp.e microcontroller is ll,sed forenabling the bl.if-·
fer
(f) Assume that a regulated supply of 5V is fed to the board from an externaJ ac-dc adttptor. Use a power jack
on the board for connecting the external supply. Use filter capacitor 0.1MFD/12Valong with the jack
(g) Use a crystal frequency of 12MHz for the microcontroller
6. Develop the PCB layout for the above requirement using 'Layout' tool. The package details for the components
are given below
Microcontroller : PDIP 40, 74LS244 : PDIP 20, Capacitor : Use a 2 Pin Package from the design library, AND
and NAND Gates: Use respective DIP package for the IC in use, 74LS138 3-8 decoder: PDIP 16, Crystal: Use
the tru:ough hole package (or 2 Pin package) for crystal from the Layout design library, Power Jack: Use the
power jack package from the library
7. Draw the schematic diagram using CaptureCIS to de-multiplex the lower order address of 8051 with the latch
74LS373 as per the requirt;ments given below
(a) The output control line of the latch is permanently grounded
(b) The ALE signal of the microcontroller is connected to the Enable line (G) of the latch
(c) The Port 0 pins are pulled to the supply voltage through 4.7K resistor
(d) The de-multiplexed address bus is connected to an 8-pin jumper (connector)
(e) Use a crystal frequency of 12MHz for the microcontroller
(f) Assume that a regulated supply of 5V is fed to the board from an external ac~dc adaptor. Use a power jack
on the board for connecting the external supply. Use filter/capacitor 0.1MFD/12V along with the jack
8. Draw the schematic diagram using CaptureCIS to interface a common c;ithode 7-Segmnet LED display through
a 74LS373 latch in memory mapped configuration with AT89C51 microcontroller as per the requirements given
below
(a) The output control line of the latch is pennanently grounded
 Embedded Hardware Design and Development

, {b) Th~.address for the.fatchjs .)!~signed as,FFOOH. Use logic gates AND, N.AND and 3 to 8 decoder IC to
. ·~~cqdelhe.~qdres& line:midcieger~t~Jb.e {l4cite~~. s~lectionpu~se for tlie guffer . .
. . .. • . • •• . ,,, •. _ • ··• . ••• •• • ,··:,c•--~,.
•...:,c.• . lltrjsq~eqfor__yuahJµigtlie
t1i~;,i~:i~:ltfG_:·-_.-.·i~~~l{;·. ·_

""'-· - .. _ - .. "_._,_

..: ,
.. . ••• C ••• •• . . . . . .
. . . Jroin an e:id~manf,d9,aqaptor.;Us~ ap~Wtlr ja<J
!~~M;'ti¥
on the board for connec ., fie ext~rn . ·, __ s' .. or:c~pabitor;QJM'R:}7J2y:~fo(g,witid!1eja¢.1( . . ·
Use a crystal frequency of12MHifor,the inicrocontroller

1
1
 ~ LEll.RNING OBJECTIVES

. :,'!m~ntr }t;4; :;i if t . .;> , . • ,, .

✓:,tlfit1,':a§cfJtfhejuAdtin1~~ta&j1J:t . .· . · . . · .. dsrngJ;wbe8dect /'P · · :. · ; , .. ,, '
✓ learn the similan"ties and. differences,· between'.conventiqnql''fc's.p.rg~tamming and 'C programming fo_cfmfiedded .
application development · · ' ·· ·. · ·· •, ' · , · · ·· ., · ·
✓ Learn the difference between native and cross-platform development
✓ Learn about Keywords and Identifiers, Data types, Storage Classes, Arithmetic and Logic Operations, Relational
Operations, Branching Instructions, Looping Instructions, Arrays and Pointers, Characters and Strings, Functions,
Function Pointers, Structures and Unions, Preprocessors and Macros, Constant Declarations, Volatile Variables; Delay
generation and Infinite loops, Bit manipulation operations, Coding Interrupt.Seivice Routines, Recursive and Reen-.
trant functions, and Dynamic memo,y allocation in Embedded C

The embedded finnware is responsible for controlling the various peripherals of the embedded hard-
ware and generating response in accordance with the functional requirements mentioned in the require-
ments for the particular embedded product. Finnware is considered as the master brain of the embedded
 Embedded Firmware Design and Development

system. Imparting intelligence to an Embedded system is a one ,time process and it can happen at any
stage, it can be immediately after the fabrication of the embedded hardware or at a later stage. Once
intelligence is imparted to the embedded product, by embedding the firmware in the hardware, the
product starts functioning properly and will continue serving the assigned task till hardware breakdown
occurs or a corruption in embedded firmware occurs. In case of hardware breakdown, the damaged
component may need to be replaced by a new component and for firmware corruptions the firmware
should be re-loaded, to bring back the embedded product to the normal functioniug. Coming back to the
newbom baby example, the newborn baby is very adaptive in terms of intelligence, meaning it learns
from mistakes and updates its memory each time a mistake or a deviation in expected behaviour occurs,
whereas most of the embedded systems are less adaptive or non-adaptive. For most of the embedded
_products.the embedded firmware is stored at a permanent memory (ROM) and they are nonalterable by
end users. Some of the embedded products used in the Control and Instrumentation domain are adap-
tive. This adaptability is achieved by making use configurable parameters which are stored in the alter-
able permanent memory area (like NVRAM/FLASH). The parameters get updated in accordance with
the deviations from expected behaviour and the firmware makes use of these parameters for creating the
response next time for similar variations.
Designing embedded firmware requires understanding of the particular embedded product hardware,
like various component interfacing, memory map details, I/O port details, configuration and register de-
tails of various hardware chips used and some programming language (either target processor/controller
specific low level assembly language or a high level language like C/C++/JAVA).
Embedded firmware development process starts with the conversion of the firmware requirements
into a program model using modelling tools like UML or flow chart based representation. The UML
diagrams or flow chart gives a diagrammatic representation of. the decision items to be taken and the
tasks to be_performed (Fig. 9.1). Once the program model is created, the next step is the implementa-
tion of the tasks and actions by capturing the model using a language which is understandable by the
target processor/controller. The following sections are designed to give an overview of the various steps
involved in the embedded firmware design and development. ·

The firmware design approaches for embedded product is purely dependent on the complexity of the
functions to be performed, the speed of operation required, etc. Two basic approaches are used for Em-
bedded firmware design. They are 'Conventional Procedural Based Firmware Design' and 'Embedded
Operating System (OS) Based Design'. The conventional procedural based design is also known as
'Super Loop Model'. We will discuss each of them in detail in the following sections.

9.1.1 The Super Loop Based Approach

The Super Loop based firmware development approach is adopted for applications that are not time
critical and where the response time is not so important (embedded systems where missing deadlines
are acceptable). It is very similar to a conventional procedural programming where the code is executed
task by task. The task listed at the top of the program code is executed first and the tasks just below the
_!

1
I
I
i'
;

Introduction to Embedded Systems

top are executed after completing the. first task. This is a true procedural one .. In a multiple task based
system, each task is executed in serial in this approach. The firmware execution flow for this will be
1. Configure the common parameters and perform initialisation for various hardware components
memory, registers, etc.
2. Start the first task and execute it
3. Execute the second task
4. Execute the next task
'5.
6.
7. Execute the last defined task
8. Jump back to the first task and follow the same flow
From the firmwar~ execution sequence, it is obvious that the order in which the tasks to be executed
are fixed and they are hard coded in the code itself. Also the operation is an infinite loop based approach.
We can visualise the operational sequence listed above in terms of a 'C' program code as

.I

Almost all tasks in embedded applications ate non-endi..ngand are repeated infinitely throughout the
operation. From the above 'C' code you can see that the tasks 1 ton are performed one after another and
when the last task (n th task) is executed, the firmware execution is again re-directed to Task 1 and it is
repeated forever in the loop. This repetition is achieved by using an infinite loop. Here the while (1) { }
loop. This approach is also referred as· 'Super loop based Approach'.
. Since the tasks are running inside an infinite loop, the only way to come out of the loop is either
a,J1ardware reset or an interrupt assertion. A hardware reset brings the program execution back to the
main lo6p. Whereas an interrupt request suspends-the task execution temporarily and performs the cor-
responding interrupt routine and on completion of the interrupt routine it restarts.the task execution from
the point where it got interrupted.
The 'Super loop based design' doesn't require an operating system, since there is no need for sched-
uling which task is ito be executed and assigning priority to each task. In a super loop based design, the
priorities are fixeq and the order in which the tasks to be executed are also fixed. Hence the code for
performing these hsks will be residing in the code memory without an operating system image.
This type of design is deployed in low-cost embedded· products and products where response time
is not time critical. Some embedded products demands this type of approach if some tasks itself are
sequential. For example, reading/writing data to and from a card using a card reader requires a sequence
of operations like checking the presence of Card, authenticating the operation, reading/writing, etc. it
 Embedded Firmware Design and Development

should strictly follow a specified sequence and the combination of these series of tasks constitutes a
single task-namely data read/write. There is no l)lse in pµt,ti1!&_the sub-tasks into independent tasks and
running them parallel. It won't work at all. ·
A typical example of a 'Super loop based' pr~duct is an electronic video game toy cont~ining keypad
and display unit. The program running inside th4 product may be designed in such a way that it reads-the
keys to detect whether the user has given any input and if any key press is detected the graphic display
js updated. The keyboard scanning and display updating happens at a reasonably high rate. Even if the
application misses a key press, it won't create any critical issues; rather it will be treated as a bug in the
firmware ©. It is not economical to embed an OS into low cost products and it is an utter waste to do so
if the response requirements are not crucial.
· . The 'Super loop based design' is simple and straight forward without any OS related overheads.
The major drawback of this approach is that any failure in any part of a single task will affect the total
system. If the program hangs up ;it some. point while executing a task, it will remain there forever and
ultimately the product stops functioning. There are remedial measures for overcoming this. Use of
Hardware and software Wa.tch Dog Timers (WDTs) helps in coming out from the loop when an unex-
pected failure.occurs or when the processor hang~ up. This, in turn, may cause additional hardware cost
and firmware overheads.
Another major drawback of.the 'Super loop' design approach is the lack of real timeliness. If the
·n.umber of tasks to be executed within an application increases, the time at which each task is repeated
,~lso increases. This brings the probability of missing out some events. For example in a system with
Keypads, according to the 'Super loop design', there will be a task for monitoring the keypad connected
I/0 lines and this need not be the task running while you press the keys (That is key pressing event may
not be in sync with the keypad press monitoring task within the firm war<;). In order to identify the key
press, you may have to press the keys for a sufficiently long t;_ime till the keypad status monitoring task
is executed internally by the firmware. This will really lead to the lack of real timeliness. There are cor-
rective measures for this also. The best advised option in use interrupts for external events requiring real
time attention. Advances in processor.technology brings out low cost high speed processors/controllers,
use of such processors in super loop, design greatly reduces the time required to service different tasks
and thereby are capable of providing a nearly real time attention to external events.
Throughout this book under the title 'Embedded Firmware Design and Development', we will be
discussing only the 'Super loop based design'. Again the discussion is narrowed to super loop based
firmware development for 8051. controller.

9.1.2 The Embedded Operating System (OS) Based Approach

\
\

The Operating System (OS) based \approach contains operating systems, which can be either a General
Purpose Operating System (GPOS) or a Real Time Operating System (RTOS) to host the user written
application firmware. The General Purpose OS (GPOS) based design is very similar to a conventional
PC based application .development where the device contains an operating system (Windows/Unix/
Linux, etc. for Desktop PCs) and you will be creating and running user applications on top of it. Ex-
ample of a ·yPOS used in emb~dded product development is Microsoft® Windows XP Embedded.
Examples of Embedded products using Microsoft® Windows XP OS are Personal Digital Assistants
(PDAs), Hand held devices/Portable devices and Point of Sale (PoS) terminals. Use of GPOS in embed-
ded products merges·the demarcation of Embedded Systems and general computing systems in terms
of OS. For Developing applications on top of the OS, the OS supported APis are used. Similar to the
 Introduction to Embedded Systems

different hardware specific drivers, OS based applications also require 'Driver software' for different
hardware present on the board to communicate with them.
Real Time Operating System (RTOS) based design approach is employed in embedded products
demanding Real-time response. RTOS respond in a timely and predictable manner to events. Real Time
operating system contains a Real Time kernel responsible for performing pre-emptive multitasking,
scheduler for scheduling tasks, multiple threads, etc. A Real Time Operating System (RTOS) allo\vs
flexible scheduling of system resources like the CPU and memory and offers some way to communicate
between tasks. We will discuss the basics of-RTOS based system design in a later chapter titled 'Design-
ing with Real Time Operating Systems (RTOS) '.
'Windows CE', 'pSOS', 'VxWorks', 'ThreadX', 'MicroCIOS-IP, 'Embedded Linux', 'Symbian' etc
are examples of RTOS employed in embedded product development. Mobile phones, PDAs (Based on
Windows CE/Windows Mobile Platforms), handheld devices, etc. are examples of 'Embedded Prod-
ucts' based on RTOS. Most of the mobile phones are built around the popular RTOS 'Symbian'.

As mentioned in Chapter 2, you can use either a target processor/controller specific language (Gener-
ally known as Assembly language or low level language) or a target processor/controller independent
language (Like C, C++, JAVA, etc. commonly known as High Level Language) or a combination of
Assembly and High level Language. We will discuss where each of the approach is used and the relative
merits and de-merits of each, in the following sections.

9. 2.1 Assembly Language based Development

'Assembly language' is the human readable notation of 'machine language', whereas 'machine lan-
guage' is a processor understandable language. Processors deal only with binaries (ls and Os). Machine
language is a binary representation and it consists of ls and Os. Machine language is made readable by
using specific symbols called 'mnemonics'. Hence machine language can be considered as an interface
between pro"cessor and programmer. Assembly language and machine languages are processor/control-
ler dependent and an assembly program written for one processor/controller family will not work with
others.
Assembly language programming is the task of writing processor specific machine code in mne-
monic form, converting the mnemonics into actual processor instructions (machine language) and
associated data using an assembler.
Assembly Language program was the most common type of programming adopted in the beginning
of software revolution. If we look back to the history of programming, we can see that a large number of
programs were written entirely in assembly language. Even in the 1990s, the majority of console video
games were written in assembly language, including most popular games written for the Sega Genesis
and the Super Nintendo Entertainment System. The popular arcade game NBA Jam released in 1993
was also coded entirely using the assembly language.
Even today also almost all low level, system related, programming is carried out using assembly
language. Some Operating System dependent tasks require low-level languages. In particular, assembly
language is often used in writing the low level interaction between the operating system and the hard-
ware, for instance in device drivers. ,
The general format of an assembly language instruction is an Opcode followed by Operands. The
Opcode tells the processor/controller what to do and the Operands provide the data and information
 Embedded Firmware Design and Development

required to perform the action specified by the opcode. It is not necessary that all opcode should have
Operands following them. Some of the Opcode implicitly contains the operand and in such situation no
... operand is required. The operand may be a single operand, dual operand or more. We will analyse each
of them with the 8051 ASM instructions as an example.

This instruction mnemonic moves decimaJ value 30 to the 8051 Accumulator register. Here MOVA
is the Opcode and 30 is the operand {single operand). The same instruction when written in machine
language will look like · ·
01110100 00011110
>where the first 8 bit binary value 01110100 represents the opq)de MOVA and the second 8 bit binary
· 'value 00011110 represents the operand 30.
" The mnemonic INC A is an example for instruction holding operand implicitly in the Opcode. The
:machine language representation of the same is 00000100. This instruction increments the 8051 Accu-
.mulator register content by 1. .
· · · The mnemonic MOVA, #30 explained above is an example for single operand instruction.
LIMP 16bit address is an examp.le for dual operand instruction. The machine language for the same
is

The first binary data is the representation of the LJMP machine code. The first operand that imme-
diately follows the opcode represents the bits 8 to 15 of t}le 16bit address to which the jump is required
anti the second operand represents the bits Oto 7 of the address to which the jump is targeted.
Assembly language instructions are written one per line. A machine .kO.de program thus consists of
a sequence of assembly language instructions, where each statement contains a mnemonic (Opcode+
Operand). Each line of an assembly language program is split into four fields as given below
LABEL OPCODE OPERAND COMMENTS
LABEL is an optional field. A 'LABEL' is an identifier used extensively in programs to reduce the reli-
ance on programmers for remembering where data or code is located. LABEL is commonly used for
representing
• A memory location, address of a program, sub-routine, code portion, etc.
• The maximum length of a label differs between assemblers. Assemblers insist strict formats for
labelling. Labels are always suffixed by a colon and begin with a valid character. Labels can con-
tain number from Oto 9 and special character (underscore).
Labels are used for representing subroutine names and jump locations in Assembly language
programming. It is to be noted that 'LABEL' is not a mandatory field; it is optional only.
The sample code given below using 8051 Assembly language illustrates the structured assembly
language programming.
. . "~# #t IHHtl##Jit-1/':lf.:~ #U~J#J# U## #####.## u ##### ##U ####
SUBROUTINEFOR GENERATING DELAY
. "PAF.hl1Et~ PASSEI2' THto&t;R't&cr·sTER Rl
RETURN VALOE NONE
USED: RO, Rl
## ## #U## ####### ###U #~HH# U ####U #### ### ## ### #######UH#######
 Introduction to Embedded Systems

; · Lg9c<l~:il~gt~.1ler :~9.·\l!~tp. 25/ji ,.: .

; ,!Jeciem.ent -Rl -and loop. till •..

; ;&T ,J~~~; ~1\. ea;~i~jr,J;a~ .~.•

The Assembly program contains· a main routine which starts at address 0000H and it may or may not
J

contain subroutines. The example given above is a subroutine, where in the main program.the subrou-
tine is invoked by the Assembly instruction
LCALL DELAY
. .
Executing this instruction transfers the program flow to the memory address referenced by the 'LA-
!1EL' DELAY.
It is a good practice to provide comments to your subroutines before the beginning of it by indicating
the purpose of that subroutine, what the input parameters are and how they are passed to the subroutines,
'Yhich are the return values, how they are returned to the calling function, etc. While assembling the
code a ';' informs the assembler that the rest of the part coming in a line after the ';' symbo1is comments
and simply ignore it. Each Assembly instruction should be written in a separate line. Unlike C and other
high level languages, more than one ASM code lines are not allowed in a single line.
In the above example the LABEL DELAY represents the reference to the start of the subroutine
DELAY. You can directly replace this LABEL by putting the desired address first and then writing the
Assembly code for the routine as given below.

The advantage of using a label is that the required address is calculated by the assembler at the
time of assembling the program and it replaces the Label. Hence even if you add some code above the
LABEL 'DELAY' at a later stage, it won't create any issues like code overlapping, whereas in the sec-
ond method where you are implicitly telling the assembler that this subroutine should start at the speci-
fied address (in the above example 0100H). If the code written above this subroutine itself is crossing
the 01OOH mark of the program memory, it will be over written by the subroutine code and it will gener-
ate unexpected results©. Hence for safety don't assign any address by yourself, let us refer the required
address by using labels and let the assembler handle the responsibility for finding out the address where
the code can be placed. In the above example you can find out that the label DELAY is used for calling
the subroutine as well as looping (using jumping instruction based pn decision~DJNZ). You can also use
the normal jump instruction to jump to the label by calling LJMP DELAY
The statement ORG OJOOH in the above example is not an assembly language instruction; it is an
assembler directive instruction. It tells the assembler that the Instructions from here onward should be
placed at location starting from 0100H. The Assembler directive instructions are known as 'pseudo-
ops'. They are _used for
1. Determining the start address of the program (e.g. ORG 0000H)
2. Determining the entry address of the program (e.g. ORG 0IO0H)
3. Reserving memory for data variables, arra~s and structures (e.g. var EQU 70H
4. Initialising variable values (e.g. val DATA 12H)
 Embedded Firmware Design and Development

The EQU directive is used for allocating memory to a variable and DATA directive is used for initial-
ising a variable with data. No macphine codes are generated for the 'pseudo-ops'.
Till now we discussed about A,~sembly language and how it is used for writing programs. Now let us
have a look at how assembly programs are organised and how they are translated into machine readable
codes.
The Assembly language program written in assembly code is saved as .asm (Assembly file) file or
an .src (source) file. Any text editor like 'notepad' or 'WordPad' from Microsoft® or the text editor
provide~ by an Integrated Development (IDE) tool can be used for writing the assembly instruction~.
_,· Similar to 'C' and other high level language programming, you can have multiple source files called
modules in assembly language programming. Each module is represented by an '.asm' or '.src' file
similar to the '.c' files in C programming. This approach is known as 'Modular Programming'. Modular
g · ··programming is employed when the program is too complex or too big. In 'Modular Programming', the
:;, entire code is divided into ~ubmodules and each module is made re-usable. Modular Programs are usu-
<i, le • ally easy to code, debug and alter. Conversion of the assembly language to mil-chine language is carried
ts out by a sequence of operations, as illustrated 'below.
9.2.1. I Source File to Object File Translation Translation of assembly code to machine code is
le performed by assembler. The assemblers for different target machines are different and it is common
that assemblers from multiple vendors are available in the market for the same target machines. Some
target processor's/controller's assembler may be proprietary and is Sl!pplied by a single vendor only.
\ Some assemblers are freely available in the internet for downloading. So~ssemblers are commercial
'· ~d requires licence from the vendor. A51 Macro Assembler from Keil software is a popular assembler
·/ for'the 8051 family microcontroller. The various steps involved in the conversion of a program written
fr· in ass~mbly language to corresponding binary file/machine language is illustrated in Fig. 9.1.

le
t
',;
1e ;,
c-

:r-

re
1g
se
•. ·So~~;fjf~·i, :i/
(4sm.ox .sn.:.Jile)... , ;~;;,--..i
I
an CM'.otiuk;}f
..
:· · ",-~
,,, .., ,,,.'
be ~ !.',.,,., .• ,,, . ; ,I-·; ,,

Machine Code
(Hex File)

~ii) Assembly language to machine language conversion process

 Introduction to Embedded Systems

Each source module is written in Assembly and is stored as .src file or .asm file. Each file can be
assembled separately to examine the syntax errors and incorrect assembly instructions. On successful
assembling of each .src/.asm file a corresponding object file is created with extension '.obj'. The object
file does not contain the absolute address of where the generated code needs to be placed on the program
memory and hence it is called a re-locatable segment. It can be placed at any code memory location and
it is th(? responsibility of the linker/locater to assign absolute address for this module. Absolute address·
allocation is done at the ab.solute object file creation stage. Each module can share variables and subrou-
tines (furtctions) among t~em. Expo!fing a variable/function from a module (making a variable/function
from a module available to all other modules) is done by declaring that variable/function as PUBLIC in
the source module.
Importing a variable or fµnction from a module (taking a variable or function from any one of other
modules) is done by declaring that variable or function as EXTRN (EXTERN) in the module where it .
is going to be ,accessed. The 'PUBLIC' Keyword informs the assembler that the variables or functions
declared as 'PUBLIC' needs to be exported. Similarly the 'EXTRN' Keyword tells the assembler that
the variables or functions declared as 'EXTRN' needs to be imported from some other modules. While
assembling a module, on seeing variables/functions with keyword 'EXTRN', the assembler understands
that these variables or functions come from an external module and it proceeds assembling the entire
module without throwing any errors, though the assembler cannot find the definition of.the variables
and implementation of the functions. Corresponding to a variable or function declared as 'PUBLIC' in a
module, there can be one or more modules using these variables or functions using 'EXTRN' keyword.
For all those modules using variables or functions with 'EXTRN' keyword, there should be one and
o~ly one module which exports those variables or functions with 'PUBLIC' keyword. If more than one
module in a project tries to export variables or functions with the same name using 'PUBLIC' keyword;
it will generate 'linker' errors.
Illustrative example for A51 Assembler-Usage of 'PUBLIC' for importing variables with same name
on different modules. The target application (Simulator) contains three modules namely ASAMPLEI.
A51, ASAMPLE2.A51 and ASAMPLE3.A51 (The file extension . A51 is the .asm extension specific
to A51 assembler). The modules ASAMPLE2.A51 and ASAMPLE3.A51 contain a function named
PUTCHAR. Both of these modules try to export this function by declaring the function as 'PUBLIC' in
the respective modules. While linking the modules, the linker identifies that two modules are exporting
the function with name P UTCHAR. This confuses the linker and it throws the error 'MULTIPLE PUB-
LIC DEFINITIONS'.
Build target 'Simulator'
assembling AS.Ak1PLE1 .A51 ...
assembling ASAl'{!PLE2 .A51, ..
assembling ASAMPLE3.A51 .••
linking... , . .
*** ERROR. t1U4.: MULTT.P;LE PlJBLIC DEFINITIONS -
SYMBOL: PUTC:H.A~ . . .. .
MODULE: · AsAt1'JLE3. bbj (CHAR__,IO)
 Embedded Firmware Design and Development

If a variable or function declared as 'EXJRN' in one or two modules, there should be one module
defining these variables or functions and exporting them using 'PUBLIC' keyword. If no modules in a
project export the variables or functions which are declared as 'EXJRN' in other modules, it will gener-
ate 'linker' warnings or errors depending on the error level/warning level settings of the linker.
Illustrative example for A5 l Assembler-Usage of EXIRN without variables exported. The target
application (Simulator) contains three modules, namely, ASAMPLE1.A51, ASAMPLE2.A51 and ASAM-
PLE3.A5 l _(The· file extension .A51 is the .asm extension specific to A51 assembler). The modules
ASAMPLEJ.A51 imports a function named PUT_CRLF which is declared as 'EXJRN' in the current
module and it expects any of the other two modules to export it using the keyword 'PUBLIC'. But none
of the other modules export this fun.9tion by declaring the function as 'PUBLIC' in the respective mod-
uies. While linking the modules, the linker identifies that there is no function exporting for this function.
'rhe linker generates a warning or error message 'UNRESOLVED EXIERNAL SYMBOL' depending on
the linker 'level' settings.

··1~t;~;!~IUl~i;~ilfl!jz1t$ 0
• ··

-9.2.1.2 Library File Creation and Usage Libraries are specially formatted, ordered program col-
lections of object modules that may be used by the linker at a later time. When the linker processes a li-
brary, only those object modules in the library that are necessary to create the program are used. Library
files are generated with extension '.lib'. Library file is some kind of source code hiding technique. If you
don't want to reveal the source code behind the various functions you have written in your program and
at the same time you want them to be distributed to application developers for making use of them in
their applications, you can supply them as library files and give them the details of the public functions
available from the library (function name, function input/output, etc). For using a library file in a project,
add the library to the project.
If you are using a commercial version of the assembler/compiler suite for your development, the ven-
dor of the utility may provide you pre-written library files for performing multiplication, floating point
arithmetic, etc. as an add-on utility or as a bonus©.
'LIB51' from Keil Software is an example for a library creator and it is used for creating library files
for A5 l Assembler/CS I Compiler for 8051 specific controller.
9.2.1.3 Linker and Locater Linker and Locater is another software utility responsible for "linking
the various object modules in a multi-module project and assigning absolute address to each module".
Linker generates an absolute object module by extracting the object modules from the library, if any
and those obj files created by the assembler, which is generated by assembling the individual modules
of a project. It is the responsibility of the linker to link any external dependent variables or functions
declared on various modules and resolve the external dependencies among the modules. An absolute
object file or module does not contain any re-locatable code or data. All code and data reside at fixed
memory locations. The absolute object file is used for creating hex files for dumping into the code
memory of the processor/controller.
'BL51' from Keil Software is an example_for a Linker & Locater for A51 Assembler/C51 Compiler
for 8051 specific controller.
9.2.1.4 Object to Hex File Converter This is the final stage in the conversion of Assembly-lan-
guage (mnemonics) to machine understandable language (machine code). Hex File is the representa-
 Introduction to Embedded Systems

tion of the machine code and the hex file is dumped into the code memory of the processor/controller.
The hex file representation varies depending on the target processor/controller make. For Intel proces-
. sors/controllers the target hex file format will be 'Intel HEX' and for Motorola, the hex file should be
in 'Motorola HEX' format. HEX files are ASCII files that contain a hexadecimal representation of
target application. Hex file is created from the final 'Absolute Object File' using the Object to Hex File
Converter utility.
'Q_H51' from Keil software is an example for Object to Hex File Converter utility for A5 l Assembler/·
C5 l Compiler for 8051 specific c~ntroller.
9.2.1.S Advantages .oL_Assembly Language Based Development Assembly Language based
development was (is©) themost common technique adopted from the beginning of embedded technol-
ogy development. Thorough understanding of the processor architecture, memory organisation, register
sets and mnemonics is very essential for Assembly Language based development. If you master .one pro-
cessor architecture and its assembly instructions, you can make the processor as flexible as a gymnast.
The major advantages of Assembly Language based development is listed below. '
Efficient Code Memory and Data Memory Usage (Memory Optjmisation) Since the devel-
oper is well versed with the target processor architecture and memory organisation, optimised code
can be written for performing operations. This leads to less utilisation of code memory and efficient
utilisation of data memory. Remember memory is a primary concern in any embedded product (Though
silicon is cheaper and new memory techniques make memory less costly, external memory operations
impac~ directly on system performance).
High Performance Optimised code not only improves the code memory usage but also improves the.
total system performance. Through effective assembly coding, optimum performance can be achieved
for a target application.
Low Level Hardware Access Most of the code .for low level programming like accessing external
device specific registers from the operating system kernel, device drivers., and low level interrupt rou-
tines, etc. are making use of direct assembly coding since low level device specific operation support is
not commonly available with most of the high-level language cross compilers.
Code Reverse Engineering Reverse engineering is the process of understanding the technology bes
hind a product by extracting the information from a finished product. Reverse engineering is performed
by 'hawkers' to reveal the technology behind 'Proprietary Products'. Though most of the products
employ code memory protection, if it may be possible to break the memory protection and read the code
memory, it can easily be converted into assembly co9e using a dis-as~embler program for the target
machine. '
9.2.1. 6 Drawbacks of Assembly Language Based Development Every technology has its
own pros and coris. From certain technology aspects assembly language development is the most ef-
ficient technique. But it is having the following technical limitations also.
High Development Time Assembly language is much harder to program than high level languages.
The developer must pay attention to 'more details and must have thorough knowledge of the architecture,
memory organisation and register details of the target processor in use. Leaming the inner details of the
processor and its assembiy inst.ructions is highly time consuming and it creates a delay impact in product
1
development. One probable solution for this is use a readily available develop er who is well versed in
 Embedded Firmware Design and Development

l,
the target processor architecture assembly instructions. Also more lines of assembly code are required
for performing an action which can be done with a single instruction in a high-level language like 'C'.
e <t
Developer Dependency There is no common written rule for developing assembly language based
,f ·f
';1 applications whereas all high level languages instruct certain set of rules for application development. In
e assembly language programming, the developers will have the freedom to choose the different memory
location and registers. Also the programming approach varies from developer to developer depending
:/ on his/her taste. For example moving data from a memory location to accumulator can be achieved
through different approaches. If the approach done by a developer is not documented properly at the
d development stage, he/she may not be able to recollect why this approach is followed at a later stage or
when a new developer is instructed to analyse this code, he/she also may not be able to understand what
:r is done and why it is done. Hence upgrading an assembly program or modifying it on a later stage is
very difficult. Well documenting the assembly code is a solution for reducing the developer dependency
t. all
in assembly language programming. If the code is too large and complex, documenting lines of code
may not be productive.

l- Non-Portable Target applications written in assembly instructions are valid only for that particular
e family of processors (e.g. Application written for Intel x86 family of processors) and cannot be re-used
lt for another target processors/controllers (Say ARMl 1 family of processors). If the target processor/con-
h troller changes, a complete re-writing of the application using the assembly instructions for the new
.s target processor/controller is required. This is the major drawback of assembly language programming
and it makes the assembly language applications non-portable.
"Though Assembly Language programming possesses lots of drawback, as a developer, from my
~
personal experience I pref1:;r assembly language based development. Once you master the internals
d ofa processor/controller, you can really perform magic with the processor/controller and can extract
the maximum out of it."
11
I- 9.2.2 High Level Language Based Development
IS
As we have seen in the earlier section, Assembly language based programming is highly time consum-
ing, tedious and requires skilled programmers with sound knowledge of the target processor architec-
:- ture. Also applications developed in Assembly-language are non-portable. Here comes the role of high
d level languages. Any high level language (like C, C++ or Java) with a supported cross compiler (for
ts converting the application developed in high level language to target processor specific assembly code
le - We will discuss cross-compilers in detail in a later section) for the target processor can be used for em-
~t bedded firmware development. The most commonly used high level language for embedded finnware
application development is 'C'. You may be thinking why 'C' is used as the popular embedded finnware
development language. The answer is "C is the well defined, easy to use high level language with exten-
ts
sive cross platform development tool support". Nowadays Cross-compilers for C++ is also emerging
f- out and embedded developers are making use of C++ for embedded application development.
The various steps involved in high level language based embedded firmware development is same as
s. that of assembly language based development except that the conversion of source file written in high
"'...,, level language to object file is done by a cross-compiler, whereas in Assembly language based develop-
te ment it is carried out by an assembler. The various steps involved in the conversion of a program written
~t in high level language to corresponding binary file/machine language is illustrated in Fig. 9.2.
m The program written in any of the high level language is saved with the corresponding language ex-
tension (.c for C, .cpp for C++ etc). Any text editor like 'notepad' or 'WordPad' from Microsoft® or the
 Introduction to Embedded Systems

Machine Code
(Hex File)
(ijg/9;2) Hfg\i'l~y,el)~#~)ge to~~9¥~~I~ri~~g~~-~i'iv~r~io; Pi~c:~s~

text editor provided by an Integrated Development (IDE) tool supporting the high level language in use
can be used for writing the program. Most of the high level languages support modular programming
approach and hence you can have multiple ·source files called modules written in corresponding high
level language. The source files corresponding to each module is represented by a file with correspond-
ing language extension. Translation of high level source code to executable object code is done by a
cross-compiler. The cross-compilers for different high level languages for the same target proce~sor are
different. It should be noted that each high level language should have a cross-compiler for convert-
ing the high level source code into the target processor machine code. Without cross-compiler support
a high level language cannot be used for embedded firmware development. C5 l Cross-compiler from
Keil software is an example for Cross-compiler. C5 l is a popular. cross-compiler available for 'C' lan-
guage for the 8051 family of micro controller. Conversion of each module's source code to correspond-
ing object file is performed by the cross compiler. Rest of the steps involved in the conversion of high
level language to target processor's machine code are same as that of the steps involved in assembly
language based development.
As an example of high level language based embedded firmware development, we will discuss how
'Embedded C' is used for embedded firmware development, in a later section of this chapter.
9.2.2.1 Advantages of High Level Language Based Development
Reduced Development Time Developer requires less or little knowledge on the internal hardware
details and architecture of the target processor/controller. Bare minimal knowledge of the memory or-
ganisation and register details of the target processor in use and syntax of the high level language are
 Embedded Firmware Design and Development

the only pre-requisites for high level language based firmware development. Rest of the things will be
taken care ofby the cross-compiler used for the high level language. Thus the ramp up time required by
the developer in understanding the target hardware and target machine's assembly instructions is waived
off by the cross compiler and it reduces the development time by significant reduction in developer ef-
fort. High level language based development also refines the scope of embedded firmware development
from a team of specialised architects to anyone knowing the syntax of the language and willing to put
little effort on understanding the minimal hardware details. With high level language, each task can be
accomplished by lesser number of lines of code compared to the target processor/controller specific As-
sembly language based development.
Developer Independency The syntax used by most of the high level languages are universal and
a·program written in the high level language can easily be understood by a second person knowing the
syntax of the language. Certain instructions may require little knowledge of the target hardware details
like register set, memory map etc. Apart from these, the high level language based firmware develop-
ment makes the firmware, developer independent. High level languages always instruct certain set of
rules for writing the code and commenting the piece of code. If the developer strictly adheres to the
rules, the firmware will be 100% developer independent.
Portability Target applications written in high level languages are converted to target processor/con-
troller understandable format (machine codes) by a cross-compiler. An application written in high level
language for a particular target processor can easily be converted to another target processor/controller
specific application, with little or less effort by simply re-compiling/little code modification followed by
re-compiling the application for the required target pr()cessor/controller, provided, the cross-compiler
has support for the processor/controller selected. This makes applications written in high level language
highly portable. Little effort may be required in the existing code to replace the target processor specific
hewer files with new header files, register definitions with new ones, etc. This is the major flexibility
offered by high level language based design.
9.2.2.2 Limitations of High Level Language Based Development The merits offered by high
level language based design take advantage over its limitations. Some cross-compilers available for high
level languages may not be so .efficient in generating optimised target processor specific instructions.
Target images created by such compilers may be messy and non-optimised in terms of performance as
well as code size. For example, the task achieved by cross-compiler generated machine instructions
from a high level language may be achieved through a lesser number of instructions if the same task is
hand coded using target processor specific machine codes. The time required to execute a task also in-
creases with the number.of instrnctions. However modem cross-compilers are tending to adopt designs
incorporating optimisation techniques for both code size and performance. High level language based
code snippets may not be efficient in accessing low level hardware where hardware access timing is
critical (of the order of nano or micro seconds).
The investment required for high level language based development tools (Integrated Development
Environment incorporating cross-compiler) is high compared to Assembly Language based firmware
development tools.

9.2.3 Mixing Assembly and High Level Language

Certain embedded firmware development situations may demand the mixing of high level language
with Assembly and vice versa. High level language and assembly languages are usually mixed in three
 Introduction to Embedded Systems

ways; namely, mixing Assembly Language with High Level Language, mixing High Level Language
with Assembly and In-line Assembly programming.
9.2.3.1 Mixing Assembly with High level language (e.g.Assembly Language with 'C') As-
sembly routines are mixed with 'C' in situations where the entire program is written in 'C' and the cross
compiler in use do not have a built in support for implementing certain features like Interrupt Service
Routine functions (ISR) or if the programmer wants to take advantage of the speed and optimised
code offered by machine code generated by hand written assembly rather than cross compiler gener-
ated machine code. When accessing certain low level hardware, the timing specifications may be very
critical and a cross compiler generated binary may not be able to offer the required time specifications
accurately. Writing the hardware/peripheral access routine in processor/controller specific Assembly
language and invoking i~ from 'C' is the most advised method to handle such situations.
. Mixing 'C' and Assembly is little complicated in the sense-the programmer must be aware of how
parameters are passed from the 'C' routine to Assembly and values are returned from assembly routine
to 'C' and how 'Assembly routine' is invoked from the 'C' code.
Passing parameter to the assembly routine and returning values from the assembly routine to the
caller 'C' function and the method of invoking the assembly routine from 'C' code is cross compiler
dependent. There is no universal written rule for this. You must get these informations from the docu-
mentation of the cross compiler you are using. Different cross compilers implement these feature,s in
different ways depending on the general purpose registers and the memory supported by the target
processor/controller. Let's examine this by taking Keil C5 l cross compil~r for 8051 controller. The ob-
jective of this example is to give an idea on how C5 l cross compiler performs the mixing of Assembly
code with 'C'. ·
1. Write a simple function in C that passes parameters and returns values the way you want your
assembly routine to.
2. Use the SRC directive (#PRAG.MA SRC at the top of the file) so that the C compiler generates an
.SRC file instead of an .OBJ file.
3. Compile the C file. Since the SRC directive is specified, the .SRC file is generated. The .SRC file
contains the assembly code generated for the C code you wrote.
4. Rename the .SRCfile to .A51 file.
5. Edit the .A51 file anq insert the assembly code you want to execute in the body of the assembly
function shell included in the .A5 l file.
As an example consider the following sample code (Extracted from Keil C51 documentation)
#pragma SRC
unsigned char my_assembly_func (unsigned-int argument)

return (argument+ 1); // Insert dummy lines to access all args and
// retvals

This C function on cross compilation generates the following assembly SRC file.
NAME TESTCODE
?PR? assembly_func?TESTCODE SEGME~T CODE
PUBLIC _my_assembly_func
#pragnu
unsigned char assembly_func
 Embedded Firmware Design and Development

RSEG ?PR?_my_assembly_func?TESTCODE
USING 0
fif"; 13: i· ,
~r:~rny assembly ·tune: .
l['.t.{::...: variable 'argurr(ent?040' assigned to Register 'R6/R7' ----
;~{~ JsouRCE L'tNE · # 2 . . . . ·
l-:/·.'.'. unslgneq. int ,..a:r:gi:u:nent)
li;\.,;J. . .
'i($:QURCE LJNE ·.#.:4 . . ...
. f' ·. '( ., .. ·t +'(1fi . I I

t,:ti:;~~i;;;,"
INC

.. RET- .•
O t. ,_:_my}~ s s~ml?,lY.o:cf up c
END

----
The special compiler directive SRC generates the Assembly code corresponding to the 'C' function
and each lines of the source code is converted to the corresponding Assembly instruction. You can easily
identify the Assembly code generated for each line of the source code since it is implicitly mentioned in
the generated .SRC file. By inspecting this code segments you can find out which registers are used for
holding the variables of the 'C' function and you can modify the source code by adding the assembly
routine you want.
9.2.3.2 Mixing High level language with Assembly (e.g. 'C' with Assembly Language)
Mixing the code written in a high level language like 'C' and Assembly language is useful in the
following scenarios:
1. The source code is already available in Assembly language and a routine written in a high level
language like 'C' needs to be included to the existing code.
2. The entire source code is planned in Assembly code for various reasons like optimised code,
optimal performance, efficient code memory utilisation and proven expertise in handling the As-
sembly, etc. But some portions of the code may be very difficult and tedious to code in Assembly.
For example 16bit multiplication and division in 8051 Assembly Language.
3. To include built in library functions written in 'C' language provided by the cross compiler. For
example Built in Graphics library functions and String operations supported by 'C'.
Most often the functions written in 'C' use parameter passing to the function and returns value/s to
the calling functions. The major question that needs to be addressed in mixing a 'C' function with As-
sembly is that how the parameters are passed to the function and how values are returned from the func-
tion and how the function is invoked from the assembly language environment. Parameters are passed
to the function and values are returned from the function using CPU registers, stack memory and fixed
memory. Its implementation is cross compiler dependent and it varies across cross compilers. A typical
example is given below for the Keil C5 l cross compiler
C5 l allows passing of a maximum of three arguments through general purpose registers R2 to R7.
If the three arguments afecnar variabtes, they are passed to-the function using registers R7, R6 and R5
 Introduction to Embedded Systems

respectively. If the parameters are int values, they are passed using register pairs (R7, R6), (RS, R4) and
(R3, R2). If the number of arguments is greater than three, the first three arguments are passed through
registers and rest is passed through fixed memory locations. Refer to C51 documentation for more
details. Return values are usually passed through general purpose registers. R7 is used for returning
char value and register pair (R7, R6) is used for returning int value. The 'C' subroutine can be in-
voked from the assembly program using the subroutine call Assembly instruction (Again cross compiler
dependent).
E.g. I.;CALL Cfunctiori

Where Cfunction is a function written in 'C'. The prefix informs the cross compiler that the parameters
to the function are passed through registers. If the function is invoked without the _ prefix, it is under-
stood that the parameters are passed through fixed memory locations.
9.2.3.3 Inline Assembly Inline assembly is another technique for inserting target processor/con-
troller specific Assembly instructions at any location of a source code written in high level language
'C'. This avoids the delay in calling an assembly routine from a 'C' code (If the Assembly instructions
to be inserted are put in a subroutine as mentioned in the section mixing assembly with 'C'). Special
keywords are used to indicate that the start and end of Assembly instructions. The keywords are cross-
compiler specific. C5 l uses the keywords #pragma asm and #pragma endasm to indicate a block of
code written in assembly.
E.g. #piagma asrri
MOY·'r1F ll3H
#p:i:-i:1gma endasm

Important Note:
The examples used for illustration throughout the section Mixing Assembly & High Level Language
is_ Keil C51 cross compiler specific. The operation is cross compiler dependent and it varies from cross
compiler to cross compiler. The intention of the author is just to give an overall idea about the mixing
ofAssembly code and High level language 'C' in writing embedded programs. Readers are advised to
go through the documentation of the cross compiler they are using for understanding the procedure
adopted for the cross compiler in use.

9.3 PROGRAMMING IN EMBEDDED C

Whenever the conventional 'C' Language and its extensions are used for programming embedded sys-
tems, it is referred as 'Embedded C' programming. Programming in 'Embedded C' is quite different
from conventional Desktop application development using 'C' language for a particular OS platform.
Desktop computers contain working memory in the range of Megabytes (Nowadays Gigabytes) and
storage memory in the range of Gigabytes. For a desktop application developer, the resources available
are surplus in quantity ands/he can be very lavish in the usage of RAM and ROM and no restrictions are
imposed at all. This is not the case for embedded application developers. Almost all embedded systems
are limited in both storage and working memory resources. Embedded application developers should
be aware of this fact and should develop applications in the best possible way which optimises the code
memory and working memory usage as well as performance. In other words, the hands of an embedded
application developer are always tied up in the memory usage context©.
 Embedded Firmware Design and Development

9.3.1 'C' v/s. 'Embedded C'

'C' is a well structured, well defined and standardise_d general purpose programming language with
extensive bit manipulation support. 'C' offers a combination of the features of high level language and
assembly and helps in hardware access programming (system level programming) as well as business
package developments (Application developments like pay roll systems, banking applications, etc). The
conventional 'C' language follows ANSI standard anq it incorporates various library files for different
operating systems. A platform (operating system) specific application, known as, compiler is used for
the conversion of programs written in 'C' to the target processor (on which the OS is running) specific
binary files. Hence it is a platform specific development.
Embedded 'C' can be considered as a subset of conventional 'C' language. Embedded 'C' supports
all 'C' instructions and incorporates a few target processor specific functions/instructions. It should be
noted that the standard ANSI 'C' library implementation is always tailored to the target processor/con-
troller library files in Embedded 'C'. The implementation of target processor/controller specific func-
tions/instructions depends upon the processor/controller as well as the supported cross-compiler for the
particular Embedded 'C' language. A software program called 'Cross-compiler' is used for the conver-
sion of programs written in Embedded 'C' to target processor/controller specific instructions (machine
language).

9.3.2 Compiler vs. Cross-Compiler

Compiler is a software tool that converts a source code written in a high level language on top of a ·
particular operating system running on a specific target processor architecture (e.g. Intel x86/Pentium).
Here the operating system, the compiler program and the application making use of the source code
run on the same target processor. The source code is cbnverted to the target processor specific machine
instructions. The development is platform specific (OS as well as target processor on which the OS is
running). Compilers are generally termed as 'Native Compilers'. A native compiler generates machine
code for the same machine (processor) on which it is running.
Cross-compilers are the software tools used in cross-platform development applications. In cross-
platform development, the compiler running on a particular target processor/OS converts the source
code to machine code for a target processor whose architecture and instruction set is different from
the processor on which the compiler is running or for an _"operating system which is different from the
current development environment OS. Embedded system development is a typical example for cross-
platform development where embedded firmware is developed on a machine with Intel/AMD or any
. other target processors and the same is converted into machine code for any other target processor ar-
chitecture (e.g. 8051, PIC, ARM etc). Keil C51 is an example for cross-compiler. The term'Compiler'
is used interchangeably with 'Cross-compiler' in embedded firn1ware applications. Whenever you see
the term 'Compiler' related to any embedded firmware application, please understand that it is referring
the cross-compiler.

9.3.3 Using 'C' in 'Embedded C'

The author takes the privilege of assuming the readers are familiar with 'C' programming. Teaching 'C'
is not in the scope of this book. If you are not familiar with 'C' language syntax and 'C' programming
technique, please get a handle on the same before you proceed. Readers are advised to go through books
by 'Brian W. Kernighan and Dennis M. Ritchie (K&R)' or 'E. Balagurusamy' on 'C' programming.
 Introduction to Embedded Systems

This section is intended only for giving readers a basic idea on how 'C' Language is used in embedded
fim1ware development.
Let us brush up whatever we learned in conventional 'C' programming. Remember we will only go
through the peripheral aspects and will not go in deep.
9.3.3.1 Keywords and Identifiers Keywords are the reserved names used by the 'C' language. All
keywords have a fixed meaning in the 'C' language context and they are not allowed for programmers
for naming their own variables or functions. ANSI 'C' supports 32 keywords and they are listed below.
All 'C' supported keywords should be written in 'lowercase' letters.

Identifiers are user defined names and labels. Identifiers can contain letters of English alphabet (both
upper and lower case) and numbers. The starting character of an identifier should be a letter. The only
special character allowed in identifier is underscore LJ.
9.3.3.2 Data Types Data type represents the type of data held by a variable. The various data types
supported, their storage space (bits) and storage capacity for 'C' language are tabulated below.
.pa ta.Type . ; :::size~!Bitst;_,
, •-,.,v,)'~'S;' -••• "'- "• , ,v'' ,,

char 8
sign~4 :c~¥r ;: ,
unsigned char
short int 8
signed short int 8
unsigned short)nt 8 . .Qtelf.
int 16 -32,7
signed int 16 -32,7
unsigned int 16
long int 32 ..
signed long int 32 -2147,4
· unsigned long int 32 0 to +4,
float 32 3.
i1double
!·'"' ·,,
64 , ,, ·l:

· long double 80
 Embedded Firmware Design and Development

The data type size and range given above is for an ordinary 'C' compiler for 32 bit platform. It should
be noted that the storage size may vary for data type depending on the cross-compiler in use for embed-
ded applications.
Since memory is a big constraint in embedded applications, select the optimum data type for a vari-
able. For example if the variable is expected to be within the range O to 255, declare the same as an
'unsigned char' or 'unsigned short int' data type instead of declaring it as 'int' or 'unsigned int'. This
i
will definitely save considerable amount of memory.
1
9.3.3.3 Storage Class Keywords related to storage class provide information on the scope (vis-
ibility or accessibility) and life time (existence) of a variable. 'C' supports four types of storage classes
and they are listed below.
. •m }'{;t~~i}i:;fff1~~~~!i>;Jiig5z;c;.jf7;~:;;~f]i1ft~:':~'
ariables:declared inside a function. Default
storage class 'is.~uto
'

Apart from these four storage classes, 'C' literally supports storage class 'global'. An 'auto or static'
variable declared in the public space of a file (declared before the implementation of all functions in-
cluding main in a file) is accessible to all functions within that file. There is no explicit storage class for
'global'. The way of declaration of a variable determines whether it is global or not.
9.3.3.4 Arithmetic Operations The list of arithmetic operators supported by 'C' are listed below
~tfi~;f.ii!:fjt9t',( Operation Comments
+ Addition Adds variables or numbers
Subtraction · Subti:acts variable;wtnririi~irf ..
* multiplication multiplies variables or numbers
Division Divides variables or num&Jht''
% Remainder Finds the remainder a division of
9.3.3.5 Logical Operations Logical operations are usually performed for decision making and
program control transfer. The list of logical operations supported by 'C' are listed below

ini~r::~t()F . Qper~tion'--
&& Logical AND Performs logical AND operation. Output is true (logic 1) if both operands (left to
and right to of && operator) are true 1

Performs '1pgicaJ
to left ◊frighfofl\ R"1S°~fft§r
0

' J > ·- ·>' --.,.:.-,,, •;-C-,•~·,"t:S,-,.,.

Logical NOT Perfo1~s logical Negation. Operand is complemented (logic Obecomes 1 and vice
versa)
 Introduction to Embedded Systems

9. 3. 3. 6 Relational Operations Relational operations arc nonnally pcrfonncd for decision making
and program control transfer on the basis of comparison. Relational operations suppo11ed by 'C' are
listed below.

9P~I~~or ,_::JPper!!fo~<:. Comments. · . ·

< less .than Checks whether the oper:a11d on the left side of ':<,'..ope;ratpr is less .than th
onthe.ri ht side. If es return logip on · · ·
rw; _-.,

ec,J, ... , eope n. n.

' _/:,· -'.\" .·::,.~;.; ;· \ ·;:.. ~- '. ' ·.•.. _,,:"
. '

9. 3. 3. 7 Branching Instructions Branching instructions change the program execution flow condi-
tionally or unconditionally. Conditional branching depends on certain conditions and if the conditions
are met, the progr_am execution is diverted accordingly. Unconditional branching instructions divert
program execution unconditionally.
Commonly used conditional branching instructions are listed below

//if statement
Evaluates the expression first and if it is true executes the statements given within
if (expression) the { } braces and continue execution of statements following the closing c:urly
{ brace (} ). Skips the execntion of the statements within the curly brace { .}'if the
statement 1; expression is false and continue execution of the statements following the closing
statement2; curly brace(}).
·············,
} One way branching
statement 3;
··············,
//if else statement
if (expression) Evaluates the expression first and if it is true executes the statements given with1n •
{ . thy {.} braces following if (expressiot1) and continue. e~ecution 'of the sfat{ffi~iG:'.
if_:_statel:nentl · following th~ closing curly brace.(}) df else bfock. Ex€~utes the statement,s'.t .
if stateinent2;
- ' : '':i;,,--,
· th~curly/brace_ { }{o~fow,ing;th,e el~e, if th~ expre~sion_iS,:·false ,:; .
>
• ·-• • ! ~ ~
-- :-.. "'
• • • ~·. ·-··•- ~··;
~
eX~$)~tio,n~ofs~atetne,ritsfollov.d~gthe:9losirig;cutly br;ce l} )'~f;lse.•
L.
i else ·;.
{,,
else'_statem:entl; .
 Embedded Firmware Design and Development

;e~e.::..statement2; Two way branching

1-
lS
rt

'{

9.3.3.8 Looping Instructions Looping instructions are used for executing a particular block of
code repeatedly till a condition is met or wait till an event is fired. Embedded programming often uses
the looping instructions for checking the status of certain I/o ports, registers, etc. and also for pro-
ducing delays. Certain devices allow write/read operations to and from some registers of the device
only when the device is ready and the device ready is normally indicated by a status register or by
setting/clearing certain bits of status registers. Hence the program should keep on reading the status
register till the device ready indication comes. The reading operation forms a loop. The looping instruc-
tions supported by 'C' are listed below.
 Introduction to Embedded Systems

Looping instruction ExplaqatiQn

//while statement
while (expression) Entry controlled loop statement.
{ The expression is evaluated first and if it is true the body of the loop is entered an~,
executed. Execution of 'body of while loop' is repeated till the expressionbecomys'
body of while loop false.

Entry controlled loop. Enters and executes the 'body of loop' only if th; iJst;'fd6
for (initialisation; test for condition is true. for loop contains a loop control variable which may be .iniHali~ecf
condition; update variable)
{
within the initialisation part of the loop. Multiple variables can be initiaJi.§¢1irtf
',' operator.
body offor loop ·
}

//skipping portion of a loop Certain situation demands the skipping of a portion of a loop for some conditioris.
The 'continue' statement used inside a loop will skip the rest of the portion following
while (expression) it and will transfer the program control to the beginning of the loop.
{ //for loop with skipping
··············,
if (condition);
continue;

i/do while with skipping

do
{

if (c9ndition) . .
continue;
. " . ..... -. ...... ..,
~ ~

}
while (expression);
 Embedded Firmware Design and Development

Every 'for' loop can be replaced by a 'while' loop with a counter.

Let's consider a typical example for a looping instruction in embedded C application. I have a device
which is memory mapped to the processor and I'm supposed to read the various registers of it (except
status register) only after the contents of its status register, which is memory mapped at 0x3000 shows
device is ready (say value 0x0l means device is ready). I can achieve this by different ways as given
1
below.
I/########IJ###################H######tl####IIIIN!I Nil#############
//using while loop
Il###ff##f!h'Nl!Jf:################################################

char *status_reg =(char*) 0x3000; //Declares memory mapped register

while (*status_regf"70x01); //Wait till status_reg= 0x0J

ll###################################################ff#######
//using do while loop
ll###########################################################

char *status_reg = (char*) Ox3000;

do
{

) while (*status_reg!=0x0J); Loop till status_reg = 0x0J

1/###########################################################
//using for loop
ll###########################################################

char *status_reg (char*) 0x3000;

for (,·(*status _reg!=Ox0J););

The instruction char *status_reg (char*) 0x3000; declares status_reg as a character pointer point-
ing to location 0x3000. The character pointer is used since the external device's register is only 8bit
wide. We will discuss the pointer based memory mapping technique in a later section. In order to avoid
compiler optimisation, the pointer should be declared as volatile pointer. We will discuss the same also
in another section.
9.3.3.9 Arrays and Pointers Array is a collection of related elements (data types). Arrays are usu-
al!i.declared with data type of array, name of the array and the number of related elements to be placed
in the array. For example the following array declaration
 Introduction to Embedded Systems

j,
1:
I' declares a character array with name 'arr' and reserves space for 5 character elements in the memory as
I in Fig. 9Jt.
I

Contents of each memory location t

Ox10 OxOO Ox23 Ox03 Ox45

Ox8000 Ox8001 Ox8002 Ox8003 Ox8004

Address of the memory location where the array elements are stored t
( Fig. 9.3) ~~ay re,p~se:iit~tion~n~e~ory:;

The elements of an array are accessed by using the array index or subscript. The index of the first
element is '0'. For the above example the first element is accessed by arr[0], second element by arr[l],
and so on. In the above example, the array starts at mem-
ory location 0x8000 (arbitrary value taken for illustra-
tion) and the address of the first element is 0x8000. The &arr[O]
'address of operator (&) returns the address of the mem-
ory location where the variable is stored. Hence &arr[0]
will return 0x8000 and &arr[l] will return 0x8001, etc.
The name of the array itself with no index (subscript)
always returns the address of the first element. If we ex-
amine the first element arr[O] of the above array, we can
see that the variable arr[0] is allocated a memory loca-
tion 0x8000 and the contents of that memory location
holds the value for arr[0] (Fig. 9.4).
Arrays can be initialised by two methods. The first method is initialising the entire array at the time
of array declaration itself. Second method is selective initialisation where any member can be initialised
or altered with a value.
//Initialization of array at the time of declaration

unsigned char arr[5] {5, JO, 20, ,3, .2};

unsigned char arr[ ] {5 , 10 ,, 2 0 , 3, 2} ;

//Selective initialization

µn,sigped char arr [ 5) ;.

arr[O) 5;
air[l] 10;
arr:[2] 20;
arr'[3] = 3;
arr[4] 2;

t Arbitrary value taken for illustration.

 Embedded Firmware Design and Development

A few important points on Arrays

L The 'sizeofO' operator returns the size of an array as the number of bytes. E.g. 'sizeof (arr)' in the
above example returns 5. If arr[] is declared as an integer array and if the byte size for integer is
4, executing the 'sizeof (arr)' instruction for the above example returns 20 (5 x 4).
2. The 'sizeofO' operator when used for retrieving the size of an array which is passed as parameter
to a function will only give the size of the data type of the array.

This code snippet will print '1' as the output, though the user expects 5 (size of arr) as output. The.
output is equivalent to sizeof (char), size of the data type of the array.
3. Use the syntax 'extern array type array name []'to access an array which is declared outside the
current file. For example 'extern char arr[]' for accessing the array 'arr[]' declared in another
file
4. Arrays.are not equivalent to pointers. But the expression' array name' is equivalent to a pointer, of
type specified by the array, to the first element of an array, e.g. 'arr' illustrated for sizeof () opera-
tor is equivalent to a character pointer pointing to the first element of array 'arr'.
5. Array subscripting is commutative in 'C' language and 'arr[k]' is same as '*((arr)+(k))' where
'arr[k]' is the content of kth element of array 'arr' and ' (arr)' is the starting address of the array arr
and k is the index of the array or offset address for the 'kth ' element from the base address of array.
'*((arr) + (k))' is the content of array for the index k.
Pointers Pointer is a flexible at the same time most dangerous feature, capable of creating potential
damages leading ta finnware crash, if not used properly. Pointer is a memory pointing based technique
for variable access and modification. Pointers are'very helpful in
1. Accessing and modifying variables
2. Increasing speed of execution
3. Accessing contents within a block of memory
4. Passing variables to functions by eliminating the use of a local copy of variables
5. Dynamic memory allocation (Will be discussed later)
To understand the pointer concept, let us have a look at the data memory organisation of a proces-
sor. For a processor/controller with 128 bytes user programmable internal RAM (e.g. AT89C51), the
memory is organised as
 Introduction to Embedded Systems

I
I

~
Ox7E
Ox7F

If we declare a character variable, say char input, the compiler assigns a memory location to the
variable anywhere within the internal memory 0x00 to 0x7F. The allocation is left to compiler's choice
unless specified explicitly (Let it be 0x45 for our example). If we assign a value (say 10) to the variable
input (input=l0), the memory cell representing the variable input is loaded with 10.

input 0x45 JO I-

The contents of memory location 0x45 (representing the variable input) can be accessed and modi-
fied by using a pointer of type same as the variable (char for the variable input in the example). It is
accomplished by the following method.
> ·:..... '.. "'-, ,· '_',;:_'c_,. :.,-t.f,:fi';i:;, "=,';;'\. ,;"'";.·xri:/~:·t,,'i:i>;\t' Y,.'1 , t,!, ·;;;4.'. ..:,.:. \'._: 7';:f:,'.'f -..c- •• _i\Ot._ ..... ,;, ··:';,':J,1 _.,,] ' .:<,'s._ati.,:;,,,.. r:rf.,
char input ({I>e,claiiiig:-:ifnp1,1(·a~ cha,rac_te·r.vari·~J\\.-~ . .
char *.p; i /D~clarif-tg fl charic;t:ecpoin,ter p" '(* ,j;l~n'.c.;'t:~s:-p is :;ii: :ix:iinter)
. )/Assigns the ·ci_actre~~ 6f'ihpJt·is'c'o'rttent·ta:p
0

p = &input

The same is diagrammatically represented as

l~~c',;-~:;;:·&*tMt~·.r~. I
I- ::.:·~~r:<~:~.;<. 'l i
r-
input 0x45 II
1
JO

pl I

[ Fig. 9.7) Pointer :based memory access te'chnique

The compiler assigns a memory to the character pointer variable 'p'. Let it be 0x00 (Arbitrary value
chosen for illustration) and the memory location holds tlie memory address of variable input (0x45)
 Embedded Firmware Design and Development

as content. In 'C' the address assignment to pointer is done using the address of operator'&' or it can
be done using explicitly by giving a specific address. The pointer feature in 'C' is same as the indirect
addressing technique used in 8051 Assembly instructions. The code snippet

is an example for 8bit memory pointer usage in 8051 Assembly and the code snippet

js an example for 16bit memory pointer operation. The general form of declaring a pointer in ',C' is

The * (asterisk) symbol informs the compiler that the variable pointer is a pointer variable. Like any
other variables, pointers can also be initialised in its declaration itself.

The contents pointed by a pointer is modified/retrieved by using* as prefix to the pointer.

Pointer Arithmetic and Relational Operations 'C'language supports the following Arithmetic
and relational operations on pointers.
1. Addition of integer with pointer. e.g. ptr+2 (It should be noted that the pointer is advanced forward
by the storage length supported by the compiler for the data type of the pointer multiplied by the
integer. For example for integer pointer where storage size of int 4, the above addition advances
the pointer by 4 x 2 = 8)
2. Subtraction of integer from pointer, e.g. ptr-2 (Above rule is applicable)
3. Incremental operation of pointer, e.g'. ++ptr and ptr++ (Depending on the type of pointer, the ++
increment context varies). For a character pointer++ operator increments the pointer by 1 and for
an integer pointer the pointer is incremented by the storage size of the integer supp011ed by the
compiler (e.g. pointer++ results in pointer+ 4 if the size for integer supported by compiler is 4)
4. Decrement operation of pointer, e.g. - -ptr and ptr- - (Context rule for decrement operation is
same as that of incremental operation)
5. Subtraction of pointers, e.g. ptrl- ptr2
6. Comparison of two pointers using relational operators, e:g. ptrl > ptr2, ptrl < ptr2, ptrl = = ptr2,
ptr 1! = ptr2 etc (Comparison of pointers of same type only will give meaningful results)

e
)
 Introduction to Embedded Systems

A few important points on Pointers

1. The instruction *ptr++ increments only the pointer not the content pointed by the pointer 'ptr' and
*ptr- - decrements the pointer not the contents pointed by the pointer 'ptr'
2. The instruction (*ptr) ++ increments the content pointed by the pointer 'ptr' and not the pointer
'ptr'. (*ptr)-- decrements the content pointed by the pointer 'ptr' and not the pointer 'ptr'
3. A type-casted pointer cannot be used in an assignment expression and cannot be incremented or
decremented, e.g. ((int *ptr))++; will not wo~k in the expected way
4. 'Null Pointer' is a pointer holding a special value called 'NULL' which is not the address of any
variable or function or the start address of the allocated memory block in dynamic memory alloca-
tions
5. Pointers of each type can have a related null pointer viz. there can be character type null pointer,
integer type null pointer, etc.
6. 'NULL' is a preprocessor macro which is literally defined as zero or ((void*) 0). #define NULL O
or #define NULL ((void*) 0)
7. 'NULL' is a constant zero and both can be used interchangeably as Null pointer constants
8. A 'NULL' pointer can be checked by the operator if ().See the following example

.•,:~!i1~.~.~~ifi(~~,r:tt}Ait;~ti~~t~t*tt~~:~f;,,,:.·•
pr}ntf )"ptr
,• • ':. h • '
ii:, .a NUJI:;. poin{~;;,ts
," • S S S, ' "~ • 0

The statement if (ptr) is ~onverted to if (ptr! =O) py the (cross) compiler. Alternatively you can
directly use the statement if (ptr! =O) in your program to check the 'NULL' pointer.
9. Null pointer is a 'C' language concept and whose internal value does not matter to us. 'NULL'
always guarantee a 'O' to you but Null pointer need not be.
Pointers and Arrays-Are they related? Arrays are not equivalent to pointers and vice versa. But
the expression array 'name [ ] ' is equivalent to a pointer, of type specified by the array, to the first ele-
ment of an array, e.g. for the character array 'char arr[5]', 'arr[]' is equivalent to a character pointer
pointing to the first element of array 'arr' (This feature is referred to as 'equivalence of pointers and
arrays'). You can achieve the array features like accessing and modifying members of an array using a
pointer and pointer increment/decrement operators. Arrays and pointer declarations are interchangeable
when they are used as parameters to functions. Point 2 discussed under the section 'A few important
points on Arrays' for sizeo/0 operator usage explains this feature also.
9. 3. 3.10 Characters and Strings Character is a one byte data type and it can hold values ranging
from Oto 255 (unsigned character) or -128 to+ 127 (signed character). The term character literally refers
to the alpha numeric characters (English alphabet A to Z (both small letters and capital letters) and num-
ber representation from 'O' to '9') and special characters like*,?,!, etc. An integer value ranging from
0 to 255 stored in a memory location can be viewed in different ways. For example, the hexadecimal
number Ox30 when represented as a character will give the character 'O' and if it is viewed as a decimal
number it will give 48. String is an array of characters. A group of characters defined within a double
quote represents a constant string.
'H' is an exa]J1ple for a character, whereas "Hello" is an example for a string. Siring always termi-
nates with a '\0' character. The '\O' character indicates the string termination. W~enever you declare a
string using a character array, allocate space for the null terminator '\O')n the array length.
 Embedded Firmware Design and Development

String operations are very important in embedded product applications. Many of the embedded prod-
ucts contain visual indicators in the form of alpha numeric displays and are used for displaying text.
Though the conventional alpha numeric displays are giving way to graphic displays, they are deployed
widely in low cost embedded products. The various operations performed on character strings are ex-
. plained below.
•
1
Input & Output operations Conventional 'C' programs running on Desktop machines make use
of the standard string inputting (scanfO) and string outputting (printf()) functions from the platform
. specific I/O library. Standard keyboard and monitor are used as the input and output inedia for desktop
application. This is not the case for embedded systems. Embedded systems are compact and they need.
not contain a standard keyboard or monitor screen for I/O functions. Instead they incorporate applica-
tion specific keyboard and display units (Alpha numeric/graphic) as user interfaces. The standard string
input instruction supported by 'C' language is scan/() and a code snippet illustrating its usage is given
below.

A standard ANSI C compiler converts this code according to the platform supported I/O library files
and waits for inputting a string from the keyboard. The scanf function terminates when a white space
(blank, tab, carriage return, etc) is encountered in the input string. Implementation of the scanf() func-
tion is (cross) compiler dependent. For example, for 8051 microcontroller all I/O operations are sup-
posed to be executed by the serial interface and the C51 cross compiler implements the-scan/() function
in such a way to expect and receive a character/string (according to the scanf usage context (character if
first parameter to scanfO is "%c" and string if first parameter is "%s")) from the serial port.
printf() is the standard string output instruction supported by 'C' language. A code snippet illustrating
the usage of print/() is given below.
~hi;J.r. name [ l "SHJBU";
printf ("%s", n,am,e);

Similar to scan/() function, the standard ANSI C compiler converts this code according to the plat-
form supported I/O library files and displays the string in a console window displayed on the monitor.
Implementation of printfO function is also (cross 2compiler specific. For 8051 microcontroller the C51
cross compiler implements the printf() function in such a way to send a character/string (according to
the printf usage context (character if first parameter to printf() is "%c" and string if first parameter is
"%s")) to the serial port.
String Concatenation Concatenation literally means 'joining together'. String concatenation refers
to the joining of two or more strings together to form a single string. 'C' supports built in functions for
string·operations. To make use of the built in string operation functions, include the header file 'string.
for
h' to your '.c' file. 'strcat()' is the function used concatenating two strings. The syntax of 'strcat()'
is illustrated below.
strcat (strl, str2); //' strl' and 's.tr2' are the strings to
)/be ~oA~~te~ated.
 Introduction to Embedded Systems

On executing the above instruction the null character ('\O ') from the end of 'strl' is removed and
'str2' is appended to 'strl'. The string 'str2' remains unchanged. As a precautionary measure, ensure
that strl (first parameter of 'strcat( )' function) is declared with enough size to hold the concatenated ·
E
string. 'strcatO' can also be used for appending a constant string to a string variable.
(
E.g. strcat(strl, ~Hello!");
t,
Note:
1. Addition of two $trings, say str l;tstr2;is .nptallowed
a
2. AddjtiJ~ of stri~g van.·,lble,';~y stri',with
.
~J~O~Stclllt string, say "Helle( \snot allowed
; ' '·' .. ,, , '
C
String Comparison Comparison of strings can be performed by using the 'strcmpO' function sup- a
ported by the string operation library file. Syntax of strcmpO' is illustrated below. a
strcmp (strl, str2); str2 are two character strings
If the two strings which are passed as arguments to 'strcmpO' function are equal, the return value of
'strcmpO' will be zero. If the two strings are not equal and if the ASCII value of the first non-match-
ing character in the string str I is greater than that of the corresponding character for the second string
str2, the return value will be greater than zero. If the ASCII value of first non-matching character in
[
the string strl is less than that of the corresponding character for the second string str2, the return value )
will be less than zero. 'strcmpO' function is used for comparing two string variables, string variable and
constant string or two constant strings.
E.g. char strl = world".;_
char str2 [ ] = ,World! 11

inf n;
n= strGmp(strl, );
Executing this code snippet assigns a value which is greater than zero ton. (since ASCII value of 'w'
is greater than that of' W). n= strcmp(str2, strl); will assign a value which is less than zero ton. (since
ASCII value of'W' is less than that of 'w').
The function stricmpO is another version of strcmp(). The difference between the two is, stricmp0
is not case sensitive. There won't be any differentiation between upper and lowercase letters when
stricmpO is used for comparison. If stricmp() is used for comparing the two strings strl and str2 in the
above example, the return value of the function stricmp (strl, str2) will be zero.
Note:
1. Comparison of two string variables using '= =' operator is invalid, ·e.g. if (strl == str2) is
invalid
2. Comparison of a string variable and a string constant using operator is also invalid, ,e.g. if
(str I == "Hello") is invalid /
I
Finding String length String length refers to the number of characters except the null 'terminator
character '\O' present in a string. Striri"gJlength can be obtained by using a coµnter combined with a
search operation for the '\O' character. 'C' supplies a ready to use string function strlenO for determining
the length of a string. Its syntax is explained below.
strlen (strl); //where strl is a character string
 Embedded Firmware Design and Development

char strl [ J = "Hello World!"

d int n;
e n = ~trlen (strl);
d Executing this code snippet assigns the numeric value 12 to integer variable 'n' .
. Copying Strings strcpyO function is the 'C' supported string operation function for copying a string
to·another string. Syntax of strcpy() function is
strcpy (strl, str2); 1/strl, ,str2 .ar1= char.ac,t~t strings .. •
This function assigns the contents of str2 to strl. The original content of strl is overwritten by the
.· contents of str2. str2 remains unchanged. The size of the character array which is passed as the first
argument the strcpy() function should be large enough to h9ld the copied string. strcpyO function can
also be used to assign constant string to string variables.

g
n
1e A few important points on Characters and Strings
d 1. The function strcatQ is used for concatenating cyvo string variables or string variable and string
co~stants. Characters cannot be appended to a string variable using strdatO function. For example
strcat (strl, 'A') may not give the expected result. The same can be achieved by strcat (strl,
"A")
2. Strings ar~haracter arrays and they cannot be assigned directly to a character array (except the
initialisation of arrays using string constants at the time of declaring character arrays)
' .. ,

I I################################## ##4t ##J#f,.##.######J#J#####~

E.g. unsigned char s~r1 [) = 'He.Uc\"/ II is'valid;
. unsigned char sfrl ! 6] ;. . .
strl= "Hello"; //is inv~lid.
0
:n 3. Whenever a character array is declared to hold a string, allocate size for the null terminator
1e character '\0' also in the character array
9.3.3.11 Functions Functions are the basic building blocks of modular programs. A function is a
self-contained and re-usable code snippet intended to perfonn a particular task. 'Embedded C' supports
two different types of functions namely, library functions and user defined functions.
Library functions are the built in functions which is either paii of the standard 'Embedded C' library
or user created library files. 'C' provides extensive built in library file support and the library files are
categorised into various types like 1/0 library functions, string operation library functions, memory
allocation library functions etc. print/(), scan/(), etc. are examples of I/O library functions. strcpy(),
)f
strcmp(), etc. are examples for string operations library functions. ma!locO, calloc() etc are examples
a
of memory allocation library functions sJpported by 'C'. All library functions supported by a particular
1g
library is implemented and exported in the same. A corresponding header ('.h') file for the library file
provides information about the various functions available to user in a library file. Users should include
the header file corresponding to a paiiicular library file for calling the functions from that library in the
 Introduction to Embedded Systems

'C' source file. For example, if a programmer wants to use the standard I/O library function printfO in
the source file, the header file corresponding to the I/O library file ("stdio.h" meant for standard i/o)
should be included in the 'c' source code using the #include preprocessor directive.

"string.h" is the header file corresponding to the built in library functions for string operations and
"malloc.h" is the header file for memory allocation library functions. Readers are requested to get info
on header files for other required· libraries from the standard ANSI library. As mentioned earlier, the
standard 'C' library function implementation may be tailored•by cross-compilers, keeping the function
name and parameter list unchanged depending on Embedded 'C' application requirements. printfO
function implemented by C5 l cross compiler for 8051 microcontroller is a typical example. The library
functions are standardised functions and they have a unique style of naming convention and arguments.
Users should strictly follow-it while using library functions.
User defined functions are programmer created functions for various reasons like modularity, easy
understanding of code, code reusability, etc. The generic syntax for a function definition (implementa-
tion) is illustrated below. ·

Return type of a function tells-what is the data type of the value returning by the function on com-
pletion of its execution. The return type can be any of the data type supported by 'C' language, viz. int,
char,fioat, long, etc. void is the return type for functions which do not return anything. Function name
is the name by which a function is identified. For user defined functions users can give any name of their
interest. For library functions the funGtion name for doing certain operations is fixed and the user should
use those standard function names. Parameters are the list of arguments to be passed to the function for
processing. Parameters are the inputs to the functions. If a function accepts multiple parameters, each
of them are separated using ',' in the argument list. Arguments to functions are passed by two means,
namely~ pass by value and pass by reference. Pass by value method passes the variables to the function
using local copies whereas in pass by reference variables are passed to the function using po.inters. In
addition to the above-mentioned attributes, a function definition may optionally specify the function's
linkage also. The linkage of the function can be either 'external' or 'internal'.
The task to be executed by the function is implemented within the body of the function. In certain
situations, you may have a single source ('.c') file containing the entire variable list, user defined func-
tions, function mainO, etc. There are two methods for writing user defined functions if the source code
is a single '.c' file. The first method is writing all user defined functions on top of the main function and
other user defined functions calling the user defined function.
 Embedded Firmware Design and Development

E.g.

· · ·. Int xyz (int i)\ .

',

If you are writing the user defined functions after the entry function mainO and calling the same
inside main, you should specify the function prototype (function declaration) of each user defined func-
tions before the function mainQ. Otherwise the compiler assumes that the user defined function is an ex-
tern function returning integer value and if you define the function after mainO without using a function
declaration/prototype, compiler will generate error complaining the user defined function is redefining
(Compiler already assumed the function which is used inside mainO without a function prototype as
an extern function returning an integer value). The function declaration informs the compiler about the
format and existence of a function prior to its use. Implicit declaration of functions is not allowed: every
function must be explicitly declared before it is called. The general form of function declara~ion is
' Linkage Type Return. type fl\nCt~qri. nar,fli?c~r:;gui.n~nt~'.) ·, .
E.g. ;static in-t add (iqt P.,. ipt bf; .. :~•,D, , . . . ''. .

The 'Linkage Type' specifies the linkage for the function. It can be either 'external' or 'internal'. The
'static' keyword for the 'Linkage Type' specifies the linkage of the function as internal whereas the 'ex-
tern' 'Linkage Type' specifies 'external' linkage for the function. It is not mandatory to specify the name

I of the argument along with its type in the argument list of the function declaration. The declarations can
simply specify the types of parameters in the argument list. This is called function prototyping. A func-
tion prototype consists of the function return type, the name of the function, and the parameter list. The
usage is illustrated below.
static int add(int, int);

Let us have a look at the examples for the different scenarios explained above on user defined func-
tions.
r;)l########H#######################################H#######l########
;/,1/E~~mple for Source code with fu~ction prototype
0
for user d:efined-::
' '//func:tions: Source file test. c · ·
t•//##U#########'##HU##########################'.#U################'###
 Introduction to Embedded Systems

#include <stdio.h>
//function prototype for user defined function test
void test (void);

void main
{
test (); //Calling user defined funcition from·main
}
/ /Implerµentat~op of -µser
voi_d 'test (vci'id)
{

return;

I I## H #0 U #U #J ###Jr# i ##U# ## ## U,# #'t! ~ ~.tH##-;~i~ # #fHJ Ul# ##

/ /Example for Source code without· fun<;tion prototype for user defined
~tlH 4t;lt #'## #_
·II functions. Source JELe test. c ,,
I I### #At#########.###_# #.#l#_##f~;#i(#:U U.JtJf## #U:ft:#.# ff#t# #f##### ##,U:fr:# ####-#
#include <stdio/h>
..//function p:r;-9fotype · for us.er defined f~'~cdcif•test not .declart/.d ·
v.oid main (.)
... , • ,,'. 1:-.' ,,.

.test () ; //Calling.)1s.ei>de~ined functi~n from ntairi

1/I~piementati6ri of ·us'er define'd furwtion' tes'f' after function main

void test (vofdl /

print£ (~Hello World!")~

return;

Compiler Output:
Compiling ...
test.c
test.c(5): warning c4013: 'test' undefined; assuming extern returning int
. test.c(9): error C2371: 'test': redefinition; different basic types Error executing cl.exe.
· test.exe-1 error(s), 1 warning(s)
There is another convenient method for declaring variables and functions involved in a source file.
This technique is a header ('.h') file and source ('.c') file based approach. In this approach, correspond-
ing to each 'c' source file there will be a header file with same name (not necessarily) as that of the 'c'
source file. All functions and global/extern variables for the source file are declared in the header file
instead of declaring the same in the corresponding source file. Include the header file where the func-
tions are declared to the source file using the "#include" pre-processor directive. Functions declared in
a file can be either global (extern access) in scope or static in scope depending on the declaration of the
 Embedded Firmware Design and Development

function. By default all functions are global in scope (accessible from outside the file where the func-
tion is declared). If you want to limit the scope (accessibility) of the function within the file where it is
declared, use the keyword 'static' before the return type in the function declaration.
9.3.3.12 Function Pointers A function pointer is a pointer variable pointing to a function. When
an application is compiled, the functions which are part of the application are also get converted into
corresponding processor/compiler specific codes. When the ·application is loaded in primary memory
for execution, the code corresponding to the function is also loaded into the memory and it resides at a
memory address provided by the application loader. The function name.maps to an address where the
first instruction (machine code) of the function is present. A function pointer points to this address.
The general form of declaration of a function pointer is given below.
. , . ,;i;~.tµr,n type (*p9i11ter "nqme). {qrgJ:im~ijl}
. , ~:v····'• ~ : '·"·~-r
1{itJ
··•-•¥· , ' •

where, 'return_type' represents the return type of the function, 'pointer_name' represents the name of
the pointer and 'argument list' represents the data type of the arguments of the function. If the function
contains multiple arguments, the data types are separated using ','. Typical declarations of function
pointer are given below.

;]!fl!if(ti::: : : : : \~~l~I~*ii;fi:~~t::tt~~r"
The parentheses () around the function pointer variable differentiates it as a function pointer variable.
If no parentheses are used, the declaration will look like
int *fpt,r~) ;
The cross compiler interprets it as a function declaration for function with name 'fptr' whose argu-
ment list is void and return value is a pointer to an integer. Now we have declared a function pointer, the
next step is 'How to assign a function to a function pointer?'.
Let us assume that there is a function with signature
int functionl{void);
and a function pointer with declaration
int (*fptr) ();

We can assign the address of the function 'fimctionl O' to our function pointer variable 'fptr' with the
_ following assignment statement:
fptr &functionl;

le. The ' & ' operator gets the address of function 'function I' and it is assigned to the pointer variable
d- 'fptr' with the assignment operator '='. The address of operator ' & ' is optional when the name of the
·c' function is used. Hence the assignment operation can be re-written as:
ile fptr functionl;
IC-
Once the address of the right sort of function is assigned to the function pointer, the function can be
Ill
he invoked by any one of the following methods.
 Introduction to Embedded Systems

( *fptr) () ; vc
fptr () ;

Function pointers can also be declared using typedef Declaration and usage of a function pointer
with typedef is illustrated below.
//Function pointer to a function.returning int and takes no parameter
. ·•- :. typ~qe{_int. (*funcptr} ();
. .' , i{ih~t1tr · fptr; ·· ·

The following sample code illustrates the declaration, definition and usage of function pointer.
Un.dude ,.~std{o. h>

Tt~~'.it::~: ::l :~.notfOb .:pbintir

· F/ v-o;i.:ti;;.t f-ptr) ( J.fltJ.; .. ·
': J~D,efiµe the _fuhction pointer to'
fptf· :'7·._s,qµarej ,·· 7•
./ · f~ ;1 :: .invoke' the 1:uncfion thr?ugii f~'ftctiO:n_: p~:i,nt~:r:;,..-:--

'
>, .j}B'.•·,.,tt{(~,2:
" .\ "
Inv~ke
.
the
""
·~un~;ici-{ thiouq~:
" "· '
tb(~{i6'ri/,P{~n:~·:{•'
•: ' " '" : "

. (ffptr}\ (2); . .· ··· · . .. · : .·

T:: ·. _ 1,·,,: :;f_~--~" . ,~ \ . t~->~,,:f_ :'.:~: .·'._~· .,_._ _ :·{ ~ _._ . . _ _, ,-.'._:·, ~t
/. /######Hi
..• ,.,.
Hi############## H### #: ####. #:H ###HUH#
,
0-U'Jf'#U#l##Ul## ##
,,. r ;-~, .. • ,t /," ,'._, . _,_, ·.; • ·- • -· ·• • ••

//Functi9n.fo:r printing the square of a number

void squ.are(iqt x)
1
pt"intf("Squa,re of %d ""•%d\ri'', x, x*x);

Function pointer is a helpful feature in late binding. Based on the situational need in the application I
you can invoke the required function by binding the function with the right sort of function pointer (The \

function signature and function pointer signature should be matching). This reduces the· usage of 'if'
and 'switch - case' statements with function names. Function pointers are extremely useful for handling
situations which demand passing of a function as argument to another function. Function pointers are
often used within functions where the function should be able to work with a number of functions whose
names are not known until the program is running. A typical example for this is callback functions, Ai
which requires the information about the function which needs to be called. Tlie following sample piece ty
of code illustrates the usage of function pointer as parameter to a function. er

#include <stdio.h>
ll#:####f######:###:#######################:#####:###:########:1####:########
//Function prototype declaraticin
void square(int x);
void cube(int x);
void power (void (*fptr) (int), int x);
 Embedded Firmware Design and Development

. void main ()

//Declare~ function pointer

void {*fptr) (int);
I /Define the function pointer to function square
fptr = square;
//Invoke .function 'square' through function poin,ter
power (fptr,2);
//Define the function pointer to £unction cube
fptr = cube;
/ /Invoke the function· 'cube' thfough''Efu,rf<:rt.ion point.er
.power . ( fptr f2) ;
,}
//#.########f###UH#####UU###########f##Uf####U########At###lt#####
//I.nt€r-face· function for invoking functiO•n·s through; cfuhct.idn pointer .

void power(void (*fptr) (int), int x)

{
(x) ;

}
l/##################1#########################1######################
//Function for printing the square of a number

void square (int x) ·

{
printf("Square of %d %d\n", x, x*x);

}
//###############1#################1#################################
//Function for printing the third power (cube) of a number
void cube(int x)

printf("Cube of %d %d\n", x, x*x*x);

Arrays of Function Poin.ters An array of function pointers holds pointers to functions with same
type of signature. This offers the flexibility to select a function using an index. Arrays of function point-
ers can be defined using either direct fonction pointers or the 'typedef qualifier.
//Declare an array of pointers to functions, which returns int and
//takes no parameters, using direct function pointer declaration
(*fnptrarr [5]) ();

//Declare and initialise an array of pointers to functions, which

//return int and takes no parameters, using direct function pointer-
//declaration
int (* rarr[]) () (/*initialisation*/};
 Introduction to Embedded Systems
0

//D~clare and initialize to 'NULL' an array of pointers to functions,

//which return int and takes no parameters, using direct function
//pointer declaration
int (*fnptrarr[5]) ()= {NULL};

//Declar~ an array of pointers to functions, which returns int and

//takes ,no pararnete~s., using typedef function pointer declaration
typedef ,a,nt (*fnc:ptr) 0;
fni:ipfi. fnptrar r[ 5] ) () ;"'
' ' ,, '
,.:··;:x\~.

IIP~S:4f;fe aqd-ini fi~Jtze an :a·rray . of point~rs to , functions, which

·I!r~tufn, int arrct fakes Ao p~:ramete'r;3, using typ~def' funthion po"inter-,-
;·1<i~:6i~a;r;ti6n · ; . ;:\• · " ··
tyf-1y4~t'int {*fncptr) (}:, ·
fn.cpt'r
'·.,.... ,, ... ,.,
friptta:1;:r[...L (
,,
{/.*inttialisa
..
tion * /};

/7Dectare and i~itialise to 'NULL' an array of pointers to •functions;

//which return int and takes nb parameters, u~ing typedef function
//p~lnter declarat~on
typ~'d,~f int: (*fncptr) ();
fncpt:t fnptrarr [ 5] (),;, · {'NULL};
The following piece of code illustrates the usage of function pointer arrays:
#include <stdio.h>
//##l#t########################t#l############t##########t#t#########
//tunction prototype definition
voi'd ·square ( int x) ;
void cube(int x);

void main ()

//Declare a function pointer array of size 2 and initialize

void (*fptr [2]) (int}:= {NULL};
//Define the functio~ pointer Oto function square
fptr[O] = square;
//Invoke the function square
fptr [OJ (2);
//Define the function pointer 1 to function cube
fptr[l] = cube;
//Invoke the funciion cube through function pointer
fptr[1]{2);
l
//####1#####################################################1########
//Function for printing the square of a number
void square(int x)

prinsf("Square of %d %d'\.n", x, x*x);

 Embedded Firmware Design and Development

9. 3. 3.13 Structures and Unions 'structure' is a variable holding a collection of data types (int,
float, char, long etc). The data types can be either unique or distinct. The tag 'struct' is used for declaring
a structure. The general form of a structure declaration is given below.

struct_name.is the name of the structure and the choice of the name is left to the programmer.
Let us examine the details kept in an employee record for an employee in the employee database of
an organisation as example. A typical employee record contains information like 'Employee Name',
'Employee Code', and 'Date of Birth'. This information can be represented in 'C' using a structure as
given below.

Hence in 'C', the employee record is represented by two string variables (character anays) and an
integer variable. Since these three variables are relevant to each employee, they are grouped together
in the form of a structure. Literally structure can be viewed as a collection of related data. The above
structure declaration does not allocate memory for the variables declared inside the structure. It's a mere
representation of the data inside a structure. To allocate memory for the structure we need to create a·
variable of the structure. The structure variable creation is illustrated below.
.struct employee empl;

Keyword 'struct' informs the compiler that the variable 'empl' is a structure of type 'employee'. The
name of the structure is referred as 'structure tag' and the variables declared inside the structure are
called 'structure elements'. The definition of the structure variable only allocates the memory for the
different elements and will not initialise the members. The members need to be initialised explicitly.
Members of the structure variable can be initfalised altogether at the time of declaration of the structure
variable itself or can be initialised (modified) independently using the '.' operator (member operator).
~mpl:= PSHIBU 21 70, " ll-1977flJ;
 Introduction to Embedded Systems

This statement declares a structure variable with name 'emp l ' of type employee and each elements
of the structure is initialised as
emp_ name = \\$HIBU K V"
emp_code = 42170
DOB= "11-11-1977"
It should be noted that the variables should be initialised in the order as per their declaration tn the
structure variable. The selective method of initialisation/modification is used for initialising /modifying
each element independently.
str1,1¢:t employee empJ;
empl. emp__pqde = "42110;;,;:

All members of a structure, except character string variables can be assigned values using '.' Opera-
tor and assignment ('=') operator (character strings are character arrays and character arrays cannot be
initialised altogether using the assignment operator). Character string variables can be assigned using
string copy function (strcpy).
s trcpy (empl . emp_ nam~:' '1 SHIB.U, K V")J·
strcpy (emp], :DOB, '!l 97

Declaration of a structure variable requires the keyword 'structure' as the first word and it may sound
awkward from a programmer point of view. This can be eliminated by using 'typedef in defining the
structure. The above 'employee' structure example can be re-written using typedef as
typedef struct
{
char emp_name [20]; // Allowe_d mqximum length name = 20.
int emp_code; . ., ' '

char DOB 'J 1 OJ ; I I DD-,MM-Y;YYY Format -(1·{;} chi:!,racter) .

} employee;
employee empl; / /No need to add stru~t befo.re employee

This approach eliminates the need for adding the keyword 'struct' each time a structure variable is
:declared.
\

.Structure operations The following table lists the various operations supported by structures

. employee.empt ,emp2;
empl.emp_code = 42170;
As'signs the values of one structure to
. (Assignment) strcpy(e!Jlpl .emp_)i,ame, ''SHIBU");
another structure of same type
strcpy(emp l .DOBtl l/11/1977'');
flIBE~~~~P!; . ,
 Embedded Firmware Design and Development

, ... e loy.e~ emp:1 &rnp2;

.. ·:. ·· ··,;'4211d;..
~WBW"fi;
. ',.?ji':))i'

Structure pointers Structure pointers are pointers to structures. It is easy to modify the memory held
by structure variables if pointers are used. Functions with structure variable as parameter-is a very good
example for it. The structure variable can be passed to the function by two methods; either as a copy of
the structure variable (pass by value) or as a pointer to a structure variable (pass by reference/address).
Pass by value method is slower in operation compared to pass by pointers since the execution time for
copying the structure parameter also needs to be accounted. Pass by pointers is also helpful if the struc-
ture which is given as input parameter to a function need to be modified and returned on execution of
the calling function. Structure pointers can be declared by prefixing the structure variable name with '* '.
The following structure pointer declaration illustrates the same. ·
.emplqyee .*empl; //structure defined \tSi.ng the struc;ture tag
f:/st;u~ture d~fined with typede-f- structure

For structure variables declared as pointers to a structure, the member selection of the structure is per-
fonned using the ' ➔' operator.
E.g. struct employee *empl, emp2;
empl &emp2; //Obtain a pointer
empl ➔ emp _ code = 421 TO;
strcpy (empl ➔ ooB, "ll-H-1977");

Structure pointers at absolute address Most of the time structures are used in Embedded C ap-
plications for representing the memmy locations or registers of chip whose memory address is fixed at
the time of hardware designing. Typical example is a Real Time Clock (RTC) which is memory mapped
at a specific address and the memory address of the registers of the RTC is also fixed. If we use a struc-
ture to define the different registers of the RTC, the structure should be placed at an absolute address
corresponding to the memory mapped address of the first register given as the member variable of the
structure. Consider the structure describing RTC registers.
typedef struct
{
:' / /RTC Control register (8bit) memory mapped at 0x4000
-~nsigned char control;
//RTC S.econds register (8bit) memory mapped at 0x4001
1i1nslgned char seconds;
 Introduction to Embedded Systems

To read and write to these hardware registers using structure member variable manipulation, we neeq
to place the RTC structure variable at the absolute address 0x4000, which is the address of the RTC
hardware register, represented by the first member of structure RTC.
The implementation of structures using pointers to absolute memory location is cross-compiler de-
pendent. Desktop applications may not give permission to explicitly place structures or pointers at
an absolute address since we are not sure about the address allocated to general purpose RAM by the
linker. Any attempt to explicitly allocate a structure at an absolute address may result in access violation
exception. More over there is no need for a general purp6se application to explicitly place structure or
pointers at an absolute address, whereas embedded systems most often requires it if different hardware
registers are memory mapped to the processor/controller memory map. The C5 l cross compiler for .
8051 microqontro}ler supports a specific Embedded C keyword 'xdata' for external memory access and
the structure absolute memory placement can be done using the following method.
' I

,:}{1~l9{;J,;}JJ0f~~llii ;'~;~:~::~~ ~Sff~~•~/i'.'•;;i., - -

Structure Arrays In the above employee record example, three important data is associated with each
employee, namely; employee name (emp_name), employee code (emp_code) and Date of Birth (DOB).
This information is held together as a structure for associating the same with an employee. Suppose the
organisation contains 100 employees then we need 100 such structures to hold the data related to the
100 employees. This is achieved by anay of structures. For the above employee structure example a
structure array with 100 structure variables can be declared as
str.w::t
-. ,· .
empl0yee,
. , ..
enip -[.iO_O]
. .:__ . ;:· . .•-.7
; cl /s~t'.1.icturn
-;~;_·_·:?\. ~?· ·•-' '
deol:aj,1~,q
-/ j, i--'f/ _-,
using
< ' -·
str:u9·t k(?y,1qrd
~-- ._,,;.._-... ~~-,, ➔,,-_-:' --/:: '.'//'':,'
-
<, -. , •. _].,f"-., ~-

~mp lo yee e_n\p (1boJ; //st::fucture'ctec1ar-ecl usirif{ypect~:f struct .

emp [0] holds the structure variable data for the first employee and emp [99] holds the structure variable
data corresponding to the 100th employee. The variables conesponding to each structure in an anay can
be initialised altogether at the time of defining the structure array or can be initialised/modified using the
corresponding array subscript for the structure and the '.' Operator as explained below.
 Embedded Firmware Design and Development

char DOB [10]; / / DD-MM-YYYY Format (10 character}

}. employee;

itialisation at the.X'.½IQ~,of:,9-efin,ing;v;<:J;rii:ible ~.,., : ,.

p:d.oyee. emp·.T3J :'t· U"JOHN'~,, .f,,jt;01-:oi t98(8'!J,.:, ..-!"AL~:K't~{,:: 2~ ''19:-01-a:19'76"},
:~MIT.fl", .a, ~'.01:...os.:.1.985"+}-; ·· · · ·
· 1ective '•inif.iali.zation

,.,
:'.~}'.;;!~}rif~;/~ame
. cpy<,{erilp'_[:0J.DOB,.
·••--"· ';, '
isr,;,1,,;.~=;:-h'"' :t1.. ·,

'
Structure in Embedded 'C' programming Simple structure variables and array of structures are
widely used in 'embedded 'C' based firmware development. Structures and structure arrays are used for
holding various configuration data, exchanging information between Interrupt Service Routine (ISR)
and application etc. A typical example for the structure usage is for holdi_ng the various register configu-
ration data for setting up a particular baudrate for serial comrnunication:;An array of such configuration
data holding structures can be used for setting different baudrates ac-cording to user needs. It is interest-
ing to note that more than 90% of the embedded C programmers use "typedef to define the structures
with meaningful names.
Structure padding (Packed structure) Structure variables are always stored in the memory of the
target system with structure member variables in the same order as they are declared in the structure
definition. But it is not necessary that the variables should be placed in continuous physical memory
locations. The choice on this is left to the compiler/cross-compiler. For multi byte processors (proces-
sors with word length greater than 1 byte (8 bits)), if the structure elements are arranged in memory in
such a way that they can be accessed with lesser number of memory fetches, it definitely speeds up the
operation. The process of arranging the structure elements in memory in a way facilitating increased
execution speed is called structure padding. As an example consider the following structure:
· typedef struct

char x; ·
int y;
} exmpl;

Let us assume that the storage space for 'int' is 4 bytes (32 bits) and for 'char' it is 1 byte (8 bits) for the
target embedded system under consideration. Suppose the target processor for embedded application,
where the above structure is making use is with a 4 byte (32 bit) data bus and the memory is byte acces-
sible. Every memory fetch operation retrieves four bytes from the memory locations 4x, 4x + 1, 4x + 2
and 4x +3, where x 0, 1, 2, etc. for successive memory read operations. Hence a 4 byte (32 bit) variable
can be fully retrieved in a single memory fetch if it is stored at memory locations with starting address
4x (x = 0, 1, 2, etc.). If it is stored at any other memory location, two memory fetches are required to
retrieve the variable and hence the speed of operation is reduced by a factor of 2.
Let us analyse the various possibilities of storing the above structure within the memory.
Method- I member variables of structure stored in consecutive data memory locations.
In this model the member variables are stored in consecutive data memory locations (Note: the
member variable storage need not start at the address mentioned here, the address given here is only
 Introduction to Embedded Systems

Memory
4x + 3 4x+2 4x + 1 4x
Address

Byte 2 of Byte l of Byte Oof

Data exmpl.x
exmpl.y exmpl.y exmpl.y

Byte 3 of
Data
exmpl.y

Memory.
4(x+l)+3 4(x+l)+2 4(x + 1) + 1 4(x + 1)
Address

for illustration) and if we want to access the character variable exmp 1.x of structure exmp 1, it can be
achieved with a single memory fetch. But accessing the integer member variable exmpl.y requires two
memory fetches.
Method-2 member variables of structure stored in data memory with padding
In this approach, a structure variable with storage size same. as that of the word length (or an integer
multiple of word length) of the processor is always placed at memory locations with starting address as
multiple of the word length so that the variable can be retrieved with a single data memory fetch. The
memory locations coming in between the first variable and the second variable of the structure are filled
with extra bytes by the compiler and these bytes are called 'p~dding byte_s' (Fig. 9.9). The structure pad-
ding technique is solely dependent on the cross-compiler in use. You can tum ON or OFF the padding of
structure by using the cross-compiler supported padding settings. Structure padding is applicable only
for processors with word size more than 8bit (1 byte). It is not applicable to processors/controllers with
8bit bus architecture.

Memory
Address 4x +3 4x+2 4x + 1 4x

Data exmpl.x

Byte 3 of Byte 2 of Byte l of Byte Oof

Data
exmpl.y exmpLy exmpl.y exmpl.y

Memory
4(x + 1) + 3 4(x + 1) +2 4(x+l)+l 4(x + 1)
Address
( Fig. 9.9) Memory representation for structure with padding

Structure and Bit fields Bit field is a useful feature supported by structures for bit manipulation
operation and flag settings in embedded applications. Most of the processors/controllers used in embed-
ded application development provides extensive Boolean (bit) operation support and a similar support
in the firmware environment can directly be used to explore the Boolean processing capability of the
target device.
 Embedded Firmware Design and Development

For most of the application development scenarios we use integer and character to hold data items
even though the variable is expected to vary in a range far below the upper limit of the data type used
for holding the variable. A typical example is flags. Flags are used for indicating a 'TRUE' or 'FALSE'
condition. Practically this can be done using a single bit and the two states of the bit (1 and 0) can be
used for representing 'TRUE' or 'FALSE' condition. Unfortunately 'C' does not support a built in data
type for holding a single bit and it forces us to use the minimum sized data type (quite often char (8bit
data type) and short int) for representing the flag. This will definitely lead to the wastage of memory.
Since memory is a big constraint in embedded applications we cannot tolerate the memory wastage. 'C'
indirectly supports bit data types through 'Bit fields' of structures. Structure bit fields can be directly ac-
cessed and manipulated. A set of bits in the structure bit field forms a 'char' or 'int' variable. The general
format of declaration of bit fields within structure is illustrated below.

e { .. ' ',.... . ,... ,

'"<' . '
)
'~a.~:~:~_tJP~ .J?:~~:F :nr }I}tl.,,;'~\t~v,~,r '.'l:.;ffi~~:' ,: .l:l.i t_:si,z;§'!;.;: ~ . ,.'" '" ~, ,,

bit.var 2 -name [,': '-~-'bit

\','··':\:7';:•>·,-'·-" ::::-: ..x _;<
size,>·
.'::.~!···::-: /''Y-:' ·;',~-:~3

r ...·..................... , '.

s ,i}pJ\t..,.Jv.a:r :fi;..:na,tne . :-J:iitfS.i:,z~;,,f,,,

e l ·•_ ;,. ,.,- -.;. , , " :. ;·;•·~·:. ·.
d 'struct name' represents the name of the bit field structure. 'data type' is the data type which will be
formed by packing several bits. Only character (char) and integer (int/short int) data types are allowed
.f in bit field structures in Embedded C applications. Some compilers may not support the 'char' data type.
y However our illustrative cross-compiler CSl supports 'char' data type as data type. 'bit_var ]_name'
h denotes the bit variable and 'bit_size' gives the number of bits required by the variable 'bit_var I_name'
and so. The operator ':' associates the number of bits required with the bit variable. Bit variables that are
packed to form a data type should be separated inside the structure using ',' operator. A real picture of
bit fields in structures for embedded applications can be provided by the Program Status Word (PSW)
register representation of 8051 controller. The PSW register of 8051 is bit addressable and its bit level
representation is given below.

P~W-1}; • PSW.6;i ,if§~~.\::\af- .. :gs1'f;nt:;~~< p~\v.o

CY AC FO RSI ov p

Using structure and bit fields the same can be represented as

struct PSW
{
char P:l, /* Bit 0 ofPSW: Parity Flag *I
: I, I* Bit I ofPSW : Unused */
OV:l, /* Bit 2 ofPSW : Overflow Flag *I
n RS0:l, /* Bit 3 ofPSW : Register Bank Select0 bit *I
l- RSJ :1, I* Bit 4 ofPSW : Register Bank Select I bit *I
rt F0:J, I* Bit 5 ofPSW: User definable Flag */
e AC :I, I* Bit 6 ofFSW : Auxiliary Carry Flag *I
C-1; I* Bit 7 ofPSW : Carry Flag*/
 Introduction to Embedded Systems

(f,Note that tM'.dperator ~; '•is1,1sed aftet!lhe,Jastbit{fjeldto

1:im]ic;ate1e11d, ~fbif/ield*{ · ·

In the above structure declaration, each bit field variable is defined with a name and an associated
bit size representation. If some of the bits are unused in a packed fashion, the same can be skipped by
merely giving the number of bytes to be skipped without giving a name for that bit variables. In the
Ai
above example Bit 1 of PSW is skipped since it is an unused bit in the PSW register.
to
It should be noted that the total number of bits used by the bit field variables defined for a specific
data type should not exceed the maximum number of allocated bits for that specific data type. In the
above example the bit field data type is 'char' (8 bits) and 7 bit field variables each of size 1 are declared
and one bit variable is declared as unused bit. Hence the total number of bits consumed by all the bit
variables including the non declared bit variable sums to 8, which is same as the bit size for the data
type 'char'. The internal representation of structure bit fields depends on the size supported by the cross-
compiler data type (char/int) and the ordering of bits in memory. Some processors/controllers store the
bits from left to right while others store from right to left (Here comes the significance of endianness).
Unions Union is a concept derived from structure and u11ion declarations follow the same syntax
as that of structures (structure tag is replaced by union tag). Though union looks similar to structure
in declaration, it differs from structure in the memory allocation technique for the member variables. . N,
Whenever a union variable is created, memory is allocated only to the member variable of union requir- th
ing the maximum storage size. But for structures, memory is allocated to each member variables. This
helps in efficient data memory usage. Even if a union variable contains different member variables of
different data types, existence is only for a single variable at a time. The size of a union returns the stor-
age size of its member variable occupying the maximum storage size. The syntax for declaring union 'i
ll(
is given below
bi
A

};

or
typedef union

/ /var-iable
. ,, .
.1 <y<':d~cl~rati,on
•;,,
'.
, ,. ' .. ;;;,; ;. -~.-,.;., .
~ ~

/ /variable ...2 ~to-.-decla,ra'tion . 9

11:::.,...) . ;1~/... ·{··,:"'.{,~i\~t{:J,,;ts:\:::\.·, u
//variabre ·n·. -a·ratiori :·<:•,\.·
p
J, q:;rf;n~ry~~~; :~:; , _;i :
s
'union_name' is the name of the union and programmers can use any name according to their program~ C

ming style. As an illustrative example let's declare a union variable consisting of an integer member s
variable and a character member variable. s
s
 Embedded Firmware Design and Development

Assuming the storage location required for 'int' as 4 bytes and for 'char' as 1 byte, the memory allocated
to the union variable exl will be as shown below

Memory
Address ~exLz---+I
4x + 3 4x+2 4x + 1 I 4x I

Byte 3 of Byte 2 of Byte 1 of Byte Oof

Data
exl.y exl.y exl.y exl.y

x =l, 2, 3... etc -----------exl.x----------'---

J~i~.2 t~~~i~if~t~l~~~i~~.~fiii1Ii~n
N,ote: The start address is chosen arbitrarily for illustration, it can be any data memory. It is obvious from the figure
that by using union the same physical address can be accessed with different data type references. Hence union is
a convenient way of 'variant access'. ·

In Embedded C applications, union may be used for fo,st acGessing of individual bytes of 'long' or
'int' variables, eliminating the need for masking the other bytes of 'long' or 'int' variables which are of
no interest, for checking some conditions. Typical example is extracting the individual bytes of 16 or 32
bit counters.
A few important points on Structure and Union
1. The ojfsetofO macro returns the offset of a member variable (in bytes) from the beginning of its
parent structure. The usage is offsetof (structName, memberName); where 'structName' is th,e
' ,/
name of the parent structure and 'memberName' is the. name of the member in the parent data
structure whose offset is to be determined. For using this macro use the header file 'stddefh'
2. If you declare a structure just before the main O function in your source file, ensure that the struc-
ture is terminated with the structure definition termination indicator ';'. Otherwise function main
() will be treated as a structure and the application may crash with exceptions.
3. A union variable can be initialised at the time of creation with the first member variable value
only.
9.3.3.14 Pre-processors and Macros Pre-processor in 'C' is compiler/cross-compiler directives
used by compiler/cross-compiler to filter the source code before compilation/cross-compilation. The
pre-processor directives are mere directions to the compilers/cross compilers on how the source file
should be compiled/cross compiled. No executable code is generated for pre-processor directives on
compilation. They are same as pseudo ops in assembly language. Pre-processors are very useful for
selecting target processor/controller dependent pieces of code for different target systems and allow a
single source code to be compiled and run on_ several different target boards. The syntax for pre-proces-
sor direct; __ •~-; is different from tbe "vntax. of'(;' lan{!uage. Each nre-nrocessor directive starts with the
 Introduction to Embedded Systems

'#' symbol and ends without a semicolon(;). Pre-processor directives are normally placed before the d,
entry point function mainO in a source file. Pre-processor directives are grouped into three categories; SI
namely V,
1. File inclusion pre-processor directives 0
2. Compile control pre-processor directives
3. Macro substitution pre-processor directives
F_ile inclusion pre processor directives The file inclusion pre processor directives include external
files containing macro definitions, function declarations, constant definitions etc to the current source
file. '#include' is the pre processor directive used for file inclusion. '#include' pre processor instruc-
tion reads the entire contents of the file specified by the '#include' directive and inserts it to the current
source file at a location where the '#include' statement is invoked. This is generally used for reading
header files for library functions and user defined header files or source files. Header files ·contain de- 7 ,'.
tails of functions and types used within the library and user created files. They must be included before
a
the program uses the library functions and other user defined functions. Library header file names are
g
always enclosed in angle brackets, < >. This instructs the pre-processor to look the standard include
· directory for the header file, which needs to be inserted to the current source file.
· e.g. #include <stdio.h> is the directive to insert the standard library file 'stdio.h'. This file is available
in the standard include directory of the development environment. (Normally inside the folder 'inc'). 11
If the file to be included is given in double quotes (" "), the pre-processor searches the file first in the '1
current directory where the current source code file is present and if not found will search the standard b
.-:zc __
include directory. Usually user defined files kept in the project folder are included using this technique. ;::-::~ s,
E.g. #include "constants.h" where 'constants' is a userdefined header file with name constants.h, kept ti
in the local project folder. An include file can include another include file in it (Nesting of include files). t(
An include file is not allowed to include the same file itself. Source files (.c) file can also be used~ n
include files. a
\ C
Compile control pre-processor directive~ Compile control pre-processor directives are used for u
controlling the compilation process such as skipping compilation of a porti9.n of code, adding debug
features, etc. The conditional control pre-processor directives are similar to the conditional statement if #
else in 'C'. #ifdef, #ifndef, #else, #endif, #undef, etc are the compile control pre-processor directives.
#ifdef uses a name as argument and returns true if the argument (name) is already defined. #define is s
used for defining the argument (name). e
#else is used for two way branching when combined with #ifdef (same as if else in 'C').
#endif is used for indicating the end of a block following #ifdef or #else
Usage of #ifdef, #else and #endifis given below.
#if def r

se {optional)
I
#endif t
The pre-processor directive #ifndef is complementary to #ifdef It is used for checking whether an
argument (e.g. macro) is not defined. Pre-processor directive #undefis used for disabling the definition
of the argument or macro if it is defined. It is complementary to #define. Pre-processor directives are I
a powerful option in source code debugging. If you want to ensure the execution of a code block, for t
 Embedded Firmware Design and Development

debug purpose you can define a debug variable and define it. Within the code wherever you want to en-
sure the execution, use the #ifdef and #endif pre-processors. The argument to #ifdef should be the debug
variable. Insert a printfO function within the #ifdef #endifblock. If no debugging is required comment
or remove the definition of debug variable.
E.g.

_cqde , block
DEBUG
hoebug Enabled") ;

The #error pre-processor directive The #error pre-processor generates error message in case of
an error and stops the compilation on accounting an error condition. The syntax of #error directive is
given below
#error error mes,sage

Macro substitution pre-processor directives Macros are a means of creating portable inline code.
'Inline' means wherever the macro is called in a source file it is replaced directly with the code defined
by the macro. In-line code improves the performance in terms of execution speed. Macros are similar to
subroutines in functioning but they differ in the way in which they are coded in the source code. Func-
t tions are normally written only once with arguments. Whenever a function needs to be executed, a call
to the function code is made with the required parameters at the point where it needs to be invoked. If a
-macro is used instead of functions, the compiler inserts the code for macro wherever it is called. From
a code size viewpoint macros are non-optimised compared to functions. Macros are generally used for
coding small functions requiring execution without latency. The '#define' pre-processor directive is
r used for coding macros. Macros can be either simple definitions or functions with arguments.
J
:,

f
#define PI 3.1415 is an example for a simple macro definition.
Macro definition can contain arithmetic operations also. Proper care should be taken in giving right
s. syntax while defining macros, keeping an eye on their usage in the source code. Consider the following
example
#define A 12+25
#define B 45-10
Suppose the source contains a statement multiplier= A *B; the pre-processor directly replaces the mac-
ros A and B and the statement becomes
multiplier= 12+25*45-10;
Due to the operator precedence criteria, this won't give the expected result. Expected result can be ob-
tained by a simple re-writing of the macro with necessary parentheses as illustrated below.
n #define A (12+25)
n #define B (45-10)
·e
Proper care should be given to parentheses the macro arguments. As mentioned earlier macros can also
lf
be defined with arguments. Consider the following example
 j .

Introduction to Embedded Systems

#define CIRCLE_AREA(a} (3.14 * a*a} p

This defines a macro for calculating the area of a circle. It takes an argument and returns the area. It OJ

should be noted that there is no space between the name of the macro (macro identifier) and the left tc
bracket parenthesis.
Suppose the source code contains a statement like area=CIRCLE AREA(5); it will be replaced as
(.3.14*5*5};
C
Suppose the call is_like this, qrea=CIRCLE AREA(2+ 5); the /pre-processor will translate the same as· A
" ,, ' _, . ,,
T
T
Will it produce the expected r,esult? Obviously no. This shortcoming in macro definition can be elimi- th
nated by using parenthesis to each occurrence of the argument. Hence the ideal solution will be; g<
. tidefine cn:RCL.E:_:_AREA.(a·):,;(3 .14 * (:aj *(a}.) cl
oJ
9.3.3.15 Constant Declarations in Embedded 'C' In embedded applications the qualifier (key- m
word) 'canst' represents a 'Read only' variable. Use of the keyword' canst' in front of a variable declares lo
that the value of the variable cannot be altered by the program. This is a kind of defensive programming m
in which any attempt to modify a variable declared as 'canst' is reported as an access violation by the
cross-compiler. The different types of constant variables used in embedded 'C' application are explained
below.
Constant data Constant data informs that the data held by a variable is always constant and can-
not be modified by the application. Constants used as scaling variables, ratio factors, various scientific
computing constants (e.g. Plank's constant), etc. are represented as constant data. The general form of
declaring a constant variable ffgiven below.
.canst ·dci.ta type• variable name;. C
er
or w
data type canst variable name; m
bE
'canst' is the keyword informing compiler/cross compiler that the variable is constant. 'data type' gives
the data type of the variable. It can be 'int', 'char', 'float', etc. 'variable name' is the constant variable.
E.g. canst float PI 3.1417;
float canst PI 3.1417;
Both of these statements declare PI as floating point constant and assign the value 3.1417 to it.
Constant variable can also be defined using the #define pre-processor directive as given below.
#,define PI 3 . 1417
/*No assignment ·using= operator and no ';' at end*/ 9.
ar
The difference between both approaches is that the first one defines a constant of a particular data
ar
type (int, char, float, etc.) whereas in the second method the constant is represented using a mere symbol
th
(text) and there is no implicit declaration about the data type of the constant. Both approaches are used
in declaring constants in embedded C applications. The choice is left to the programmer.
 Embedded Firmware Design and Development

Pointer to constant data Pointer to constant data is a pointer which points to a data which is read
only. The pointer pointing to the data can be changed but the data is non-modifiable. Example of pointer
to constant data -
const int*:,,;.; //Integer,point:er x to constant data
int const* x I I Same meEi~i'rrg as above defirt1tion" · . ·

Constant pointer to data Constant pointer has significant importance in Embedded C applications.
An embedded system under consideration may have various external chips like, data memory, Real
Time Clock (RTC), etc interfaced to the target processor/controller, using memory mapped technique.
The range of address assigned to each chips and their registers are dependent on the hardware design. At
the time of designing the hardware itself, address ranges are allocated to the different chips and the tar-
get hardware is developed according to these address allocations. For example, assume we have an RTC
chip which is memory mapped at address range 0x3000 to 0x3010 and the memory mapped address
of register holding the time information is at 0x3007. This memory address is fixed and to get the time
information we have to look at the register residing at location 0x3007. But the content of the register
located at address 0x3007 is subject to change according to the change in time. We can access this data
using a constant pointer. The declaration of a constant pointer is given below.
• "•• ,, ••• '/' ! < '• ·~~. c' •~ ' ,,,

J Constant charicter ,point~r ·,x t·b -c0nst1nt/>1a:t.iable _'data

liar. Jcons t x; ·
\"~~ ,, t
l . ;" · .::', ·.: ·!.'- .: ..-,, ·
• ' '. ' -
-
·• . . ·, ·._, -- -:_:;~- !v- . .:. ;···;-::, .•r - -"\ • :·',~ :;·,::,;~-· ·i::-J:·'~ . l-.>;t:i\':T:·(.;-~_ ·:·;\·-1.r:-: ~. - ..
xplipit d~cla;cat_i6,n pt:·,cnara9ter .poi1:1ter ·pofnting, to, 8bit, rriem0ry, location,
•_pe_d at loca,tion.0.~)00,7:: iirrc'-'~~an:ig,le 'Jnifs.tiqti4
,.,,.-.:: ' :.<·· ·,_-,__-'.,·,:_.1/~?-~.t'""
,-L --: j_: .,;, ;- >, ·,,, '.:/•_ , ··:;·./-:·f.~,;-,_, . ::l"-·:·--~-
;,'.:i,¼ • • ·.,
::~bpye~/'. ' .'. ,
,., .
f

Constant pointer to constant data . Constant pointers pointing to constant data are widely used in
embedded programming applications. Typical uses are reading configuration data held at ROM chips
which are memory mapped at a specified address range, Read only status registers of different chips,
memory mapped at a fixed address. Syntax of declaring a constant pointer to constant data is given
below.
s
d*Constant character pointer x pointing to constant data*/
-~onst char *const x;
¢har const* coast x; //Equivalent to above declaration

/*Explicit declaration of constant character pointer* pointing to constant

"data/
~~har const* canst x = (char*} Ox3007;

9.3.3.16 The 'Volatile' Type Qualifier in Embedded 'C' The keyword 'volatile' prefixed with
any variable as qualifier informs the crofas-compiler that the value of the variable is subject to change at
ta
:,l any point of time (subject to asynchronous modification) other than the current statement of code where
the control is at present.
Examples of variables which are subject to asynchronous modifications are
1. Variables common to Intenupt Serv:ice Routines (ISR) and other functions of a file
2. Memory mapped hardware registers
 ,•11'·/g;

. Introduction to Embedded Systems

.
-
3. Variables shared by different threads in a multi threaded application (Not applicable to Super loop
Firmware development approach)
The 'volatile' keyword informs the cross-compiler that the variable with 'volatile' qualifier is subject
to asynchronous change and there by the cross compiler turns off any optimisation (assumptions on the Voli
variable) for these variables. The general form of declaring a volatile variable is given below. cal e
dym
foe(;
belo
'data type' refers to the data type of the variable. It can be int, char, float, etc. 'variable name' is the user
defined name for the volatile variable of the specified type.

What is the catch in using 'volatile'variable? Let's examine the following code snippet.

9.3.
plic,
fore
user
On cross-compiling the code snippet, the cross-compiler converts the code to a read operation from
asyr
the memory location mapped at address 0x3000 and it will assume that there is no point where the vari- dela
able is going to modify (sort of over smartness) and may keep the data in a register to speed up the exe- ave
cution. The actual intention of the programmer, with the above code snippet is to read a memory mapped plo)
hardware status register and halt the execution of the rest of the code till the status register shows a ready eml:
status. Unfortunately the program will not produce the expected result due to the oversmartness of the I
cross-compiler in optimising the code for execution speed. Re-writing the code as given below serves brar
the intended purpose. acc1
I /Declan:i's ;volatile variable. dep
vo_latile cha,r *status_reg = (char *) Ox3000; lay~
in ( .
while (*status reg!=OxOl); //Wait till status reg OxOl Del
free
In embedded applications all memory mapped device registers which are subject to asynchronous var
modifications (e.g. status, control and general purpose registers of memory mapped external devices) by,
should be declared with 'volatile' keyword to inform the cross-compiler that the variables represent- for
ing these registers/locations are subject to asynchronous changes and do not optimise them. Another
area which needs utmost care in embedded applications is variables shared between ISR and functions Int
(variables which can be modified by both Interrupt Sub Routines and functions). These include structure/ tati
variable, union variable and other ordinary variables. To avoid unexpected behaviour qf the applicationJ/
always declare such variables using 'volatile' keyword. '
The 'constant volatile'Variable Some variables µsed in embedded applications s::an be both 'con-
stant' and 'volatile'. A 'Read only' status register of a,,memory mapped device ,is a typicc1-l example for
Ini
this. From a user point of view the 'Read only' status registers can only be read but cannot· modify.
Hence it is a constant variable. From the device point the contents can be modified at any time by the
device. So it is a volatile variable. Typical declarations are given ahead.
 Embedded Firmware Design and Development

.I I Constant volatile integer .

j /Pointer
.--.
;to a. Constant ...volatile integer
;

Volatile pointer Volatile pointers is subject to change at any point after they are initialised. Typi-
cal examples are pointer to arrays or buffers modifiable by Interrupt Service Routines and pointers in
dynamic memory allocation. Pointers used in dynamic memory allocation can be modified by the real-
locO function. The general form of declaration of a volatile pointer to a non-volatile variable is given
/

~~ .

.,. •,.;>trn•~}Jt~if~~-~F#::~~·· ·
Volatile pointer to a volatile variable is declared with the following syntax.

9.3.3.17 Delay Generation and Infinite Loops in Embedded C Almost every embedded ap-
plication involves delay programming. Embedded applications employ delay programming for waiting
for a fixed time interval till a device is ready, for inserting delay between displays updating to give the
user sufficient time to view the contents displayed, delays involved in bit transmission and reception in
asynchronous serial transmissions like l2C, I-Wire data transfer, delay for key de-bouncinK etc. Some
delay requirements in .embedded application may be critical, meaning delay accuracy should be within
a very narrow tolerance band. Typical example is delay used in bit data transmission. If the delay em-
ployed is not accurate, the bits may lost while transmission or reception. Certain delay requirements in
embedded application may not be much critical, e.g. display updating delay.
It is easy to code delays in desktop applications under DOS or Windows operating systems. The li-
brary function delay0 in DOS and Sleep Oin Windows provides delays in milliseconds with reasonable
accuracy. Coding delay routines in embedded applications is bit difficult. The major reason is delay is
dependent on target system's clock frequency. So we need to have a trial and error approach to code de-
lays demanding reasonably good accuracy. Refer to the code snippet given for 'Perfom1ance Analyser'
in Chapter 14 for getting a handle on how to code delay _routine in embedded applications using IDEs.
Delay codes are generally non-portable. Delay routine requires a complete re-work if the target clock
frequency is changed. Normally 'for loops' are used for coding delays. Infinite loops are created using
various loop control instructions like while (), do while (), for and goto labels. The super lQQp creat~d_
by while (1) instruction in a traditional super loop based embedded firmware design is a typical example
for infinite loop in embedded application development.
Infi.nite loop using while The following code snippet illustrates 'while' for infinite loop implemen-
tation.
while (1)

Infinite loop using do while

i;
'::-· do

} while (1);
 Introduction to Embedded Systems

Infi.nite loop using for 13

u
s
ti
Infi.nite loop using goto 'goto' when combined with a 'label' can create infinite loops. b

E
·l
b

Which technique is the best? According to all experienced Embedded 'C' programmers whileO
loop is the best choice for creating infinite loops. There is no technical reason for this. The clean syntax
of while loop entitles it for the same. The syntax offor loop for infinite loop is little puzzling and it is
not capable of conveying its intended use. 'goto' is the favorite choice of programmers migrating from
Assembly to Embedded C ©.
break; statement is used for coming out of an infinite loop. You may think why we implement an in-
finite loop and then quitting it? Answer - There may be instructions checking some condition inside the
infinite loop. If the condition is met the program control may have to transfer to some other location.
9.3.3.18 Bit Manipulation Operations Though Embedded 'C' does not support a built in Boolean E
variable (Bit variable) for holding 'a 'TRUE (Logic l)' or 'FALSE (Logic O)' condition, it provides ex- a
tensive support for Bit manipulation operations. Boolean variables required in embedded application are
quite often stored as variables with least storage memory requirement (obviously char variable). Indeed
it is wastage of memory if the application contains large number of Boolean variables and each variable
, is stored as a char variable. Only one bit (Least Significant bit) in a char variable is used for storing
Boolean information. Rest 7 bits are left unused. This will definitely lead to serious memory bottle
neck. Considerable amount of memory can be saved if different Boolean variables in an application are
1
packed into a single variable in 'C' which requires less memory storage bytes. A character variable can
C
accommodate 8 Boolean variables. If the Boolean variables are packed for saving memory, depending
upon the program requirement each variable may have to be extracted and some manipulation (setting,
clearing, inverting, etc.) needs to be performed on the bits. The following Bit manipulation operations (
are employed for the same.
V
Bitwise AND Operator '&' performs Bitwise AND operations. Please note that the Bitwise AND
operator ' &' is entirely different from the Logical AND operator ' && '. The ' &' opera.tor acts on indi-
vidual bits of the operands. Bitwise AND operations are usually perfonned for selective clearing of bits
and testing the present state of a bit (Bitwise ANDing with 'l '). 1
l:
Bitwise OR Operator' I' performs Bitwise OR operations. Logical OR operator 'II' is in no way relat-
ed to the Bitwise OR operator 'I'. Bitv,ise OR operation is performed on individual bits of the operands. I
Bitwise OR operation is usually performed for selectively setting of bits and testing the current state of
a bit (Bitwise ORing with 'O'). '
f
Bitwise Exclusive OR- XOR Bitwise XOR operator 'A' acts on individual operand bits and perfonns
an 'Excusive OR' operation on the bits. Bitwise XOR operation is used for toggling bits in embedded J
applications. t
 Embedded Firmware Design and Development

Bitwise NOT Bitwise NOT operations negates (inverts) the state of a bit. The operator '~' (tilde) is
used as the Bitwise NOT operator in C.
Setting and Clearing and Bits Setting the value of a bit to '1' is achieved by a Bitwise OR opera-
tion. For example consider a character variable (8bit variable) flag. The following instruction sets its 0th
bit always 1.
flag = flag I i;

Brief explanation about the above operation is given below.

Using 8 bits, 1 is represented as 00000001. Upon a Bitwise OR each bit is ORed with the corresponding
.·,,
bit of the operand as illustrated below.

'.o Bit 0 of flag is ORed with 1 and Resulting o/p bit=l

··•
:lX
Bit 1 of flag is ORed with 0 and Resulting o/p bit= Bit 1 of flag
IS
Bit 2 of flag is ORed with 0 and Resulting o/p bit= Bit 2 of flag
,m Bit 3 of flag is ORed with 0 and Resulting o/p bit= Bit 3 of flag
Bit 4 of flag is ORed with 0 and Resulting o/p bit= Bit 4 of flag
n- Bit 5 of flag is ORed with 0 and Resulting o/p bit= Bit 5 of flag
he Bit 6 of flag is ORed with 0 and Resulting o/p bit= Bit 6 of flag
Bit 7 of flag is ORed with 0 and Resulting o/p bit= Bit 7 of flag

an Bitwise OR operation combi~ed with left shift operation of' l' is used for selectively setting any bit in
:x- a variable. For example the following operation will set bit 6 of char variable flag.
tre i;t\\r>••~-~ '•. ' ' '
I

,,,1/1/Sets 6.th bit of·

ed l!f~~i;\Z"ui~ ( ·- (1 J·tJ}
,le-- {
Re-writing the above code for a neat syntax will give
ng
tle ·~

lfC
The same can also be achieved by bitwise ORing the variable flag with a mask with 6th bit '1' and all
:an
other bits '0', i.e. mask with 01000000 in Binary representation and 0x40 in hex representation.
ng
!lg, flag I= Ox4 0; //Equivalent to flag = flag I (1 :<'<6) ;
ms Clearing a desired bit is achieved by Bitwise ANDing the bit with 'O'. Bitwise AND operation combined
with left shifting of' 1' can be used for clearing any desired bit in a variable.
\fD ,:Example:
di- flag &= ~ (1« 6 ) ;
,its
The above instruction will clear the 6th bit of the character variable flag. The operation is illustrated
below.
lat- Execution of (l <<6) shifts' l 'to six positions left and the resulting output in binary will be 01000000.
ldS. Inverting this using the Bitwise NOT operation (~ (1 <<6)) inverts the bits and give 10111111 as output.
: of When flag is Bitwise ANDed with 10111111, the 6th bit offlag is cleared (set to '0') and all other bits of
flag remain unchanged.
ms From the above illustration it can be inferred that the same operation can also be achieved by a direct
ied Bitwise ANDing of the variable flag and a mask with binary representation 10111111 or hex representa-
tion 0xBF.
 Introduction to Embedded Systems

'ii0 rii:ig• ,flag

<"' ···, ,,·.;
~ 0:

Shifting the mask ' l' for setting or clearing a desired bit works perfectly, if the operand on which these tt
operations are performed is 8bit wide. If the ·operand is greater than 8 bits in size, care should be taken
to adjust the mask as wide as the operand. As an example let us assume flag as a 32bit operand. For
(,
clearing the 6th bit offlag as illustrated in the previous example, the mask 1 should be re-written as 'lL' ;"

and the instruction becomes 6

7
tl
Toggling Bits ' (

Toggling a bit is performed to negate (toggle) the current state of a bit. If current state of a specified bit
is 'l ', after toggling it becomes 'O' and vice versa. Toggling is also known as inverting bits. The Bitwise a
f(
XOR operator is used for toggling the state of a desired bit in an operand.
C
C

The above instruction toggles bit 6 offlag. t(

11
Adding 'J' to the desired bit position (In the above example 0x40 for 6th bit) will also toggle the current
state of the desired bit. This approach has the following drawback. If the current state of the bit which
is to be inverted is 'I', adding a 'I' to that bit position inverts the state of that bit and at the same time
a carry is generated and it is propagated to the next most significant bit (MSB) and change the status of
some of the other bits falling to the left of the bit which is toggled.
Extracting and Inserting Bits . 1'
Quite often it is meaningful to store related information as the bits of a single variable instead of saving , t:
them as separate variables. This saves considerable amount of memory in an embedded system where t
data memory is a big bottleneck. Typical scenario in embedded applications where information can be
stored using the bits of single variable is, information provided by Real Time Clock (RTC). RTC chip
provides various data like current date/month/year, day of the week, current time in hours/minutes/
seconds, etc. If an application demands the storage of all these information in the data memory of the
embedded system for some reason, it can be achieved in two ways; 1:
1. Use separate variables for storing each data (date, month, year, etc.) t
2. Club the related data and.store them as the.bits of a single variable 1
As an example assume that we need to store the date information of the RTC in the data memory in
D/M/Y format. Where 'D' stands for date varying from 1 to 31, 'M' stands for month varying from 1
to 12 and 'Y' stands for year varying from Oto 99. If we follow the first approach we need 3 character 1
variables to store t]:ie date information separately. In the second approach, Wf!! need only 5 bits for date
(With 5 bits we can represent Oto 25 -1 numbers (0 to 31 ), 4 bits for month and 7 bits for year. Hence
the total number of bits required to represent the date information is 16. All these bits can be fitted into
a 16 bit variable as shown in Fig. 9.11.

1-
I
◄ ---Bit 9 tol5
115
---►l-•- Bit 5 to 8 -+ Bit Oto 4 --l>l
' j QI

Year (0 to 99) \ Month (1 to 12) Date (1 to 31)

( Fig. 9 .11) Packed Bits for data representation

 Embedded Firmware Design and Development

Suppose this is arranged in a 16bit integer variable date, for any calculation requiring 'Year', 'Month'
or 'Date', each should be extracted from the single variable date. The following code snippet illustrates
the extraction of 'Year'
:n
)r
(date>>9) shifts the contents 9 bits to the left and now 'Year' is stored in the variable date in bits Oto
L'
6 (including both). The contents of other bits (7 to 15) are not relevant to us and we need only th~ first
7 bits (0 to 6) for getting the 'Year' value. ANDing with the mask 0x7F (01111111 in Binary) retains
the contents of bits Oto 6 and now the variable year contains the 'Year' value extracted from variable
'date'.
•it Similar to the extracting of bits, we may have to insert bits to change the value of certain data. In the
above example if the program is written in such a way that after each I minute, the RTC's year register is
read and the contents of bit fields 9 to 15 in variable 'date' needs to be updated with the new value. This
can be achieved by inserting the bits corresponding to the data into the desired bit position. Following
code snippet illustrates the updating of 'Year' value for the above example. To set the new 'Year' value
to the variable 'date' all the corresponding bits in the variable for 'Year' should be cleared first. It is il-
lustrated below.

The mask for 7 bits is 0x7F (01111111 in Binary). Shifting the mask 9 times left aligns the mask to
that of the bits for storing 'Year'. The~ operator inverts the 7 bits aligning to the bits corresponding to
'Year'. Bitwise ANDing with this negated mask clears the current bits for 'Year' in the variable 'date'.
Now shift the new value which needs to be put at the. 'Year' location, 9 times for bitwise alignment for
tg the bits corresponding to 'Year'. Bitwise OR the bit aligned new value with the 'date' variable whose
:e bits corresponding to 'Year' is already cleared. The following instruction performs this.
,e
tp
s/ where 'new__year' is the new value for 'Year'.
Le In order to ensure the inserted bits are not exceeding the number of bits assigned for the particular
bit variable, bitwise AND the new value with the mask corresponding to the number of bits allocated to
the corresponding variable (Above example 7 bits for 'Year' and the mask is 0x7F). Hence the above·
instruction can be written more precisely as
1n
date I= (new_year & 0x7F) <<9;
1
If all the bits corresponding tothe bit field to be modified are not set to zero prior to Bitwise ORing
te with the new value, any existing bit with value '1' will remain as such and expected° result will not be
:e obtained.
:o
Testing Bits So far we discussed the Bitwise operators for changing the status of a selected bit. Bit-
wise operators can also be used for checking the present status of a bit without modifying it for decision
making operations.
. if (flag & (1<<6)} //Checks whether 6th bit of flag is '1'
This instruction examines the status of the 6th bit of variable flag. The same can also be achieved by
using a constant bit mask as
(flag & 0x40.) //Checks whether 6th ~it of flag is. '1'
 Introduction to Embedded Systems

9.3.3.19 Coding Interrupt Service Routines (ISR) Interrupt is an event that stops the current
1I
execution of a process .(task) in the CPU and transfers the program execution to an address in code
ir
memory where the service routine for the event is located. The event which stops the current execu-
fi
tion can be an internal event or an external event or a proper combination of the external and internal
ir
event. Any trigger signal coming from an externally interfaced device demanding immediate attentions
3J :
is an example for external event whereas the trigger indicating the overflow of an internal timer is an
VI
example for internal event. Reception of serial data through the serial line is a combination of internal
tl
and external events. The number of interrupts supported, their priority levels, interrupt trigger type and
VI
the structure of interrupts are processor/controller architecture dependent and it varies from processor
d
to processor. Interrupts are generally classified into two: Maskable Interrupts and Non-maskable Inter-
rupts(NMI). Maskable interrupt can be ignored by the CPU if the interrupt is internally not enabled or
t1
if the CPU is currently engaged in processing another interrupt which is at high priority. Non-maskable
interrupts are interrupts which require urgent attention and cannot be ignored by the CPU. Reset (RST)
interrupt and TRAP interrupt of 8085 processor are examples for Non-maskable interrupts.
· Interrupts are considered as boon for programmers and their main motto is "give real time behav-
iour to applications". In a processor/controller based simple embedded system where the application is
designed in a super loop model, each interrupt supported by the processor/controller will have a fixed
memory location assigned in the code memory for writing its corresponding service routine and this
address is referred as Interrupt Vector Address. The vector address for each interrupt will be pre-de-
fined and the number of code memory bytes allocated for each Interrupt Service Routine, starting from
the Interrupt Vector Address may also be fixed. For example the interrupt vector address for interrupt
'INTO' of 8051 microcontroller is '0003H' and the number of code memory bytes allowed for writing
its Service routine is 8 bytes.
The function written for serving an Interrupt is known as Interrupt Service Routine (ISR). ISR for
each interrupt may be different and they are placed at the Interrupt Vector Address of corresponding ,,
Interrupt. ISR is essentially a function that takes no parameters and returns no results. But, unlike a tc
regular function, the ISR can be active at any time since the triggering of interrupts need not be in sync fi
with the internal program execution (e.g. An external device connected to the external interrupt line can
assert external interrupt at any time regardless at what stage the program execution is currently). Hence
special care must be taken in writing these functions keeping in mind; they are not going to be executed
in a pre-defined order. Vlhat all special care should be taken in writing an ISR? The following section
answers this query.
Imagine a situation where the application is doing some operations and some registers are modified
and an interrupt is triggered in between the operation. Indeed the program flow is diverted to the Inter-
rupt Service Routine, if the interrupt is an enabled interrupt and the operation in progress is not a service
routine of ? high priority interrupt, and the ISR is executed. After completing the ISR, the program
flow is re-directed to the point where it got interrupted and the interrupted operation is continued. What
happens if the ISR modifies some of the registers used by the program? No doubt the application will
produce unexpected results and may go for a toss. How can this situation be tackled? Such a situation
can be avoided if the ISR is coded in such a way that it takes care of the following:
1. Save the current context (Important Registers which the ISR will modify)
2. Service the Interrupt
3. Retrieve the saved context (Retrieve the original contents of registers) c
4. Return to the execution point where the execution is interrupted f
Normal functions will not incorporate code for saving the current context before executing the func- t
l
tion and retrieve the saved context before exiting the function. ISR should incorporate code for perform-
 Embedded Firmware Design and Development

ing these operations. Also it is known to the programmer at what point a normal function is going to be
invoked and the programmer can take necessary precautions before calling the function, it is not the case
for an ISR. Interrupt Service Routines can be coded either in Assembly language-or High level language
in which the application is written. Assembly language is the best choice if the ISR code is very small
and the program itself is written in Assembly. Assembly code generates optimised code for ISR and user
will have a good control on deciding what all registers needs to be preserved from alteration. Most of
the modem cross-compilers provide extensive support for efficient and optimised ISR code. The way in
which a function is declared as ISR and what all context is saved within the function is cross-compiler
dependent.
Keil C5 l Cross-complier for 8051 microcontroller implements the Interrupt Service Routine using
the keyword interrupt and its syntax is illustrated below.

.interrupt_name is the function name and programmers can choose any name according to his/her taste.
The attribute 'interrupt' instructs the cross compiler that the associated function is an interrupt service
routine. Ihe interrupt attribute takes an argument x which is an integer constant in the range Oto 31
(supporting 32 interrupts). This number is the interrupt number and it is essential for placing the gener-
ated hex code corresponding to the ISR jn the corresponding Interrupt Vector Address (e.g. For placing
the ISR code at code memory location 0003H for Interrupt 0-Extemal Interrupt Ofor 8051 microcon-
troller). using is an optional keyword for indicating which register bank is used for the general purpose·
· Registers RO to R7 (For more details on register banks and general purpose registers, refer to the hard-
ware description of 8051). The argument y for using attribute can take values from Oto 3 (corresponding
to the register banks Oto 3 of 8051 ). The interrupt attribute affects the object code of the function in the
following way:
1. If required, the contents of registers ACC, B, DPH, DPL, and PSW are saved on the stack at func-
tion invocation time.
2. All working registers (RO to R?) used in the interrupt function are stored on the stack if a register
bank is not specified with the using attribute.
3. The working registers a~d special registers that were saved on the stack are restored before exiting
the function.
4. The function is terminated by the 8051 RETI instruction.
Typical usage i& illustrated below
void external interruptO (void interrupt O using 0

adc control *adc~contfol_reg //Read memory mapped ADC

// control Register
}

If the cross-compiler you are using don't have a built in support for writing ISRs, What shall you
do? Don't be panic you can implement the ISR feature with little tricky coding. If the cross-compiler
provides support ~or mixing high level language-C andjAssefu;bly, write the ISR in Assembly and place
the ISR codbat the corresponding Interrupt Vector addtess usit'lg the cross compiler's support for plac-
ing the code in an absolute addres~ location of code·meindry (Using keywords like at. Refer to your
' , - I
 Introduction to Embedded Systems

cross compiler's documentation for getting the exact keyword). If the ISR is too complicated, you can
place the body of the ISR processing in a normal C function and call it from a simple assembly language
wrapper. The assembly language wrapper should be installed as the ISR function at the absolute address
corresponding to the Interrupt's Vector Address. It is responsible for executing the current context sav-
ing and retrieving instructions. Current context saving instructions· are written on top of the call to the
'C' function and context retrieving instructions are written just below the 'C' function call. It is little
puzzling to find answers to the following questions in this approach.
1. Which registers must be saved and restored since we are not sure which registers are used by the
cross compiler for implementing the 'C' function?
2. How the assembly instructions can be interfaced with high-level language like 'C'?
Answers to these questions are cross compiler dependent and you need to find the answer by referring
the documentation files of the cross-compiler in use. Context saving is done by 'Pushing' the registers
(using PUSH instructions) to stack and retrieving the saved context is done by 'Poping' (using POP
instructions) the pushed registers. Push and Pop operations usually follow the Last In First Out (LIFO)
method. While writing an ISR, always keep in mind that the primary aim of an interrupt is to provide
real time behaviour to the program. Saving the current context delays the execution of the original ISR
function and it creates Interrupt latency (Refer to the section on Interrupt Latency for more details) and
thereby adds lack of real time behaviour to an application. As a programmer, if you are responsible for
saving the current context by Pushing the registers, avoid Pushing the registers which are not used by
the ISR. If you deliberately avoid the saving of registers which are going to be modified by the ISR, your
application may go for a toss. Hence Context saving is an unavoidable evil in Interrupt driven program-
ming. If you go for saving unused registers, it will increase interrupt latency as well as stack memory
usage. So always take a judicious decision on the context saving operation. If the cross compiler offers
the context saving operation by supporting ISR functions, always rely on it. Because most modem cross
compilers are smart and capable of taking a judicious decision on context saving. In case the cross com-
piler is not supporting ISR function and as a programmer you are the one writing ISR functions either
in Assembly or by mi1ing 'C' and Assembly, ensure that the size ofISR is not crossing the size of code
memory bytes alloweo for an Interrupt's ISR (8 bytes for 8051). If it exceeds, it will overlap with the
location for the next interrupt and may create unexpected behaviour on servicing the Interrupt whose
Vector address got overlapped.
9.3.3.20 Recursive Functions A function which calls itself repeatedly is called a Recursive Func-
tion. Using recursion, a complex problem is split into its single simplest form. The recursive function
only knows how to solve that simplest case. Recursive-functions are useful in evaluating certain types
of mathematical function, creating and accessing dynamic data structures such.as linked lists or binary
trees. As an example let us consider the factorial calculation of a number.
By mathematical definition
n factorial= I x 2 x ....... (n 2) x (n - 1) x n; where n = I, 2, etc ... and Ofactorial= 1
Using 'C' the function for finding the factorial of a number 'n' is written as
int n)

int coun't;
\ \ \
for {cou~t==i; . . . ; count+.~)\\
1 ·
factorial'1<=count; · t
 Embedded Firmware Design and Development

.n return factorial;
:e
;s
,_ This code is based on iteration. The iteration of calculating the repeated products is performed until
te the count value exceeds the value of the number whose factorial is to be calculated. We can split up the
le . ·. task performed inside the function as count * (count +1) till count is one short of the number whose
{ factorial is to be calculated. Using recursion we can re-write the above function as
te

•'

g
'.S
p
))
le Here the function factorial (n) calls itself, with a changed version of the parameter for· each call,
R inside the same for calculating the factorial of a given number. The 'if' statement within the recursive
d function forces the function to stop recursion when a certain criterion is met. Without an 'if' statement a
lr recursive function will never stop the recursion process. Recursive functions are very effective in imple-
,y menting solutions ·expressed in terms of a successive application of the same solution to the solution
tr subsets. Recursion is a powerful at the same time most dangerous feature which may lead to application
l- crash. The local variables of a recursive function are stored in the stack memory and new copies of each
y variable are created for successive recursive calls of the function. As the recursion goes in a deep level,
'.S stack memory may overflow and the application may bounce.
;s
Recursion vs. Iteration: .A comparison Both recursion and iteration is used for implementing cer-
l-
tain operations which are self repetitive in some form.
~r
• Recursion involves a lot of call stack overhead and function calls. Hence it is slower in operation
le
compared to the iterative method. Since recursion implements the functionality with repeated
te
self function calls, more stack memory is required for storing the local .variables and the function
:e
return address ·
• R\;cursion is the best method for implementing certain operations like certain mathematical opera-
tion, creating and accessing of dynamic data structures such as linked lists or binary trees
• A recursive solution implementation can always be replaced by iteration. The process of convert-
ing a recursive function to iterative method is called 'unrolling'
y
Benefits of Recursion Recursion brings the following benefits in programming:
• Recursive code is very expressive compared to iterative code. It conveys the intended use.
• Recursion is the most appropriate method for certain operations like permutations, search trees,
sorting, etc.
Drawbacks of Recursion Though recursion is an effective technique in implementing solutions ex-
pressed in terms of a successive application of the.same solution to the solution subsets, it possesses the
following drawbacks.
• Recursive operation is slow in operation due to call stack overheads. It involves lot of stack opera-
tions like local variable storage and retrieval, return address storage and retrieval, etc.
• Debugging of recursive functions are not so easy compared to itt;:rative code debugging
 Introduction to Embedded Systems

9.3.3.21 Re-entrant Functions Functions which can be shared safely with several processes
concurrently are called re-entrant functions. When a re-entrant function is executing, another process
can interrupt the execution and can execute the same re-entrant function. The "another process" re-
ferred here can be a thread in a multithreaded application or can be an Interrupt Service Routine (ISR).
Re-entrant function is also referred as 'pure' function. Embedded applications extensively make use of
re-entrant functions. Interrupt Servfoe Roµtines (ISR) in Super loop based firmware systems and threads
in RTOS based systems can change the program's control flow to alter the current context at any time.
When an interrupt is asserted, the current operation is put on hold and the control is transferred to an-
other function or task (ISR). Imagine a situation where an interrupt occurs while executing a function
x and the ISR also contain the task of executing thefanction x. What will happen? - Obviously the ISR
will modify the shared variables offunction x and when the control is switched back to the point where
the execution got interrupted, the function will resume its execution with the data which is modified by
the ISR. What will be the outcome of this action? - Unpredictabl.e result causing data corruption and
potential disaster like application break-down. Why it happens so? Due to the corruption of shared data
in function which is unprotected. How this situation can be avoided? By carefully controlling the shar-
ing of data in the function.
In embedded applications, a function/subroutine is considered re-entrant if and only if it satisfies the
following criteria.
1. The function should not hold static data over successive calls, or return a pointer to static data.
2. All shared variables within the function are used in an atomic way.
3. The function does not call any other non-reentrant functions within it.
4. The function does not make use of any hardware in a non-atomic way
Rule# 1 deals with variable usage and function return value for a reentrant function. In an operating ·
system based embedded system, the embedded application is managed by the operating system services
and the 'memory manager' service of the OS kernel is responsible for allocating and de-allocating the
memory required by an application for its execution. The working memory required by an application is
divided into three groups namely; stack memory, heap memory and data memory (Refer to the Dynamic
Memory Allocation section of this chapter for more details). The life time of static variables is same as
that of the life time of the application to which it belongs and they are usually held in the data memory
area of the memory space allocated for the application. All static variables of a function are allocated
in the data memory area space of the application and each instance of the function shares this, whereas
local (auto) variables of a function are stored in the stack memory and each invocation of the function
creates independent copies of these variables in the stack memory. For a f4nction to be reentrant, it
should not keep any data over successive invocations (the function should nol contain any static stor-
age). If a function needs some data to be kept over successive invocations, it should be provided through
the caller function instead of storing it in the function in the form of static. variables. If the function
returns a pointer to a staJic data, each invocation of the function makes use of this pointer for returning
the result. This can be tackled by using caller function provided storage for passing the data back to the
caller function. The 'callee' function needs to be modified accordingly to mak~use qf the caller function
provided storage for passing the data back to the caller. · ·
Rule# 2 deals with 'atomic' operations. So what does 'atomic' mean in reentrancy context? Meaning
the ope,r1ftion cannot be interrupted. If an embedded application contain~ variables which are shared
between various threads of a multitasking system (Applicable to. Operating System based embedded
systems) or between the application and ISR (In Non-RTOS. based embedded systems), and if the
operation on the shared variable is non-atomic, there is a possibility for corruption of the variable due
 Embedded Firmware Design and Development

to concurrent access of the variable by multiple threads or thread and JSR. As an example let us assume
that the variable counter is shared between multiple threads or between a thread and ISR, the instruction,

need not operate in an 'atomic' way on the variable counter. The compiler/cross-compiler in use con-
verts this high level instruction into machine dependent code (machine language) and the objective of
incrementing the variable counter may be implemented using a number of low level instructions by
the compiler/cross compiler. This violates the 'atomic' rule of operation. Imagine a situation where an
execution switch (context switch) happens when one thread is in the middle of executing the low level
instructions corresponding to the high level instruction counter++, of the function and another thread
(which is currently in execution after the context switch) or an ISR calls the same function and executes
the instruction counter++, this will result in inconsistent result. Refer to the section 'Racing' under the
topic 'Task Synchronisation Issues' of the chapter 'Designing with Real Time Operating Systems' for
more details on this. Eliminating shared global variables and making them as variables local to the func-
tion solves the problem of modification of shared variables by concurrent execution of the function.
Rule# 3 is selfexplanatory. If a re-entrant function calls another function which is non-reentrant, it
may create potential damages due to the unexpected modification of shared variables if any. What will
happen if a reentrant function calls a standard library function at run time? By default most of the run
time library is reentrant. If a standard library function is not reentrant the function will no longer be
reentrant.
Rule# 4 deals with the atomic way of accessing hardware devices. The term 'atomic' in hardware ac-
cess refers to the number of steps involved in accessing a specific register of a hardware device. For the
hardware access to be atomic the number of steps involved in hardware access should be one. If access
is achieved through multiple steps, any interruption in between the steps may lead to erroneous results.
A typical example is accessing the hardware register of an I/O device mapped to the host CPU using
paged addressing technique. In order to Read/Write from/to any of the hardware registers of the device
a minimum of two steps is required. First write the page address, corresponding to the page in which
the hardware register belongs, to the page register and then read the r~gister by giving the address of
the register within that page. Now imagine a situation where an interrupt occurs at the moment execut-
ing the page setting instruction in progress. The ISR will be executed after finishing this instrµction.
Suppose JSR also involves a Read/Write to another hardware register belonging to a different page.
Obviously it will modify the page register of the device with the required value. What will be its impact?
On finishing the ISR, the interrupted code will try to read the hardware register with the page address
which is modified by the ISR. This yields an erroneous result.
How to declare a function as Reentrant The way in which a function is declared reentrant is cross-
compiler dependent. For Keil C51 cross-compiler for 8051 controller, the keyword 'reentrant' added as
function attribute treats the function as reentrant. For each reentrant function, a reentrant stack area is
simulated in internal or external memory depending whether the data memory is internal or external to
the processor/controller. A typical reentrant function implementation for C51 cross-compiler for 8051
controller is given below. ··
· int multiply (char. i,. int b) re.entrant
0

{
 l!ltroduction to Embedded Systems };
t,~

The simulated stack used by reentrant functions has its own stack pointer which is independent of
·her
th,e processor stack and stack pointer. For C51 cross compiler the simulated stack and stack pointers are
apf
declared and initialised in the startup code in STARTUP.A51 which can be found,in the LIB subdirec-
var
tory. You must modify the startup code to specify which simulated stack(s) to initialize in order to use
tak
re:-entrant functions. You can also modify the starting address for the top of the simulated stack(s) in
Vlfl
the startup code. When calling a function with a re-entrant stack, the cross-compiler must know that the
Thi
function has a re-entrant stack. The cross-compiler figures this out from the function prototype which .,. ign
should include the reentrant keyword (just like th~ function definition). The cross compiler must also
the
know which reentrant stack to stuff the arguments for it. For passing arguments, the cross-compiler gen-
dai
erates code that decrements the stack pointer and then "pushes" arguments onto the stack by storing the
de•
argument indirectly through R0/Rl or DPTR (8051 specific registers). Calling reentrant function decre- if 1
ments the stack pointer (for local variables) and access arguments using the stack pointer plus an offset the
iss ~t
(which corresponds to the number of bytes oflocal variables). On returning, reentrant function adjusts
. the stack pointer to the value before arguments were pushed. So the caller does not need to perform any m(
stack adjustment after calling a reentrant function. on
Reentrant vs. Recursive Functions The terms Reentrant and Recursive may sound little confusing. ag
You may find some .amount of similarity among them and ultimately it can lead to the thought are Re- Al
entrant functions and Recursive functions the same? The answer is-.it depends on the usage context of
the function. It is not necessary that all recursive functions are reentrant. But a Reentrant function can sy
be invoked recursively by an application. m
For.8051 Microcontroller, the internal data memory is very small in size (128 bytes) and the stack ·ro
as'~ell user data memory is allocated within it. Normally all variables local to a function and function ar
arguments are stored in fixed memory locations of the user data memory and each invocation of the
function will access the fixed data memory and any recursive calls to the function use the same memory
locations. And, in this case, arguments and locals would get corrupted. Hence the scope for implement-
ing recursive functions is limited. A reentrant function can be called recursively to a recursion level
dependent on the simulated stack size for the same reentrant function.
CS l Cross-compiler does not support recursive calls if the functions are non-reenjrant.
9.3.3.22 Dynamic Memory Allocation Every embedded application, regardless Qf whether it is
running on an operating system based product. br a non-operating system based product (Super loop
based finnware Architecture) contains different types of variables and they fall into any one of the fol-
lowing storage types namely; static, auto, global or constant data. Regardless of the storage type each
variable requires memory locations to hold them physically. The storage type determines in which
area of the memory each variable needs to be kept. For an Assembly language programmer, handling
memory for different variables is quite difficult. S/he needs to assign a particular memory location for
each variable and should recollect where s/he kept the variable for operations involving that variable.
Certain category of embedded applications deal with fixed number of variables with fixed length and
certain other applications deal with variables with fixed memory length ·as well as variable with total
storage size determined only at the runtime of application (e.g. character array with variable size). If the
number of variables are fixed in an application and if it doesn't require a variable size at run time, the
cross compiler can determine the storage memory required by the application well in advance at the run
time and can assign each variable an absolute address or relative (indirect) address within the data mem-
ory. Here the memory required is fixed· and allocation is done before the execution of the application.
This type of memory allocation is referred as 'Static Memory Allocation'. The term 'Static' mentioned
 Embedded_Firmware Design and Development

f ,here refers 'fixed' and it is no way related to the storage class static. As mentioned, some embedded
·applications require data memory which is a combination of fixed memory (Number of variables and
variable size is known prior to cross compilation) and variable length data memory. As an example, let's
'take the scenario where an application deals with reading a stream of character data from an external en-
vironment and the length of the stream is variable. It can vary between any numbers (say 1 to 100 bytes).
The application needs to store the data in data memory temporarily for some calculation and it can be
. , ignored after the calculation. This scenario can be handled in two ways in the application progra,ril. In
·' the first approach, allocate fixed memory with maximum size (say.100 bytes) for storing the incoming
'data bytes from the stream. In the second approach allocate memory at run time of the application and
de-allocate(free) the memory once the data memory storage requirement is over. In the first approach
if the memory is allocated fixedly, it is locked forever.and cannot r:e-used by the application even if
there is no requirement for the allocated number of bytes and it will definitely create memory bottleneck
issues in embedded systems where memory is a big constraint. Hence it is not advised to go fot fixed
memory allocations for applications demanding variable memory size at run time. Allocating memory
on demand al).d freeing the memory at run time is the most advised method for handling the stor-
age of dynamic (changing) data and this memory allocation technique is known as 'Dynamic Memory
Allocation'.
Dynamic memory allocation technique is employed in Operating System (OS) based embedded
systems. Operating system contains a 'Memory Management Unit' and it is responsible for handling
memory allocation related operations. The memory management unit allocates memory to hold the code
·ror the application and the variables associated with the application. The conceptual view of storage of
· an application and the variables related to the application is represented 1n Fig. 9.12.

--r- ---
Auto Variables
- --- --

Dynamic Storage
Memory '

~ --- ----" ---- --

Free Memory Heap

Alterable Data

Static Storage
Constant Data
Memory

Source Code

@lg. ~.12) Static and Dy~amir. M~mor:y Storage Allocation

 Introduction to Embedded Systems

Memory manager allocates a memory segment to each application and the memory segment holds w
the source code of the application as well as data related to the application. The actual program code m
(executable machine code instructions) is stored at the lower address of the memory (at the beginning
address of the memory segment and stores upward). Constant data related to the application (e:g. canst
int x = IO;) is stored at the memory area just above the executable code. The alterable data (global and w
static variables; e.g. static int}= 10; int k= 2; (global declaration), etc.) are stored at the 'Alterable Data' to
memory area. The size of the executable code, the number of constant data and alterable data in an ap-
plication is always fixed and hence they occupy only a fixed portion of the memory segment. Memory
allocated for the executable code, constant data and alterable data together constitute the 'Static storage
memory (Fixed storage memory)'. The storage memory available within the memory segment exclud-
ing the fixed memory is the 'Dynamic storage _memory'. Dynamic storage memory area is divided into
two separate entities namely 'stack' and 'heap'. 'Stack memory' normally starts at the high memory.
area (At the top address) of the memory segment and grows down. Within a memory segment, fixed v:
number of storage bytes are allocated to stack memory and the stack can grow up to this maximum al- el
located size. Stack memory is usually used for holding auto variables (variables local to a function), ft
function parameters and function return values. Depending upon the :fqnction calls/return and auto vari-
- able storage, the size of the stack grows and shrinks dynamically. If at any point of execution the stack
memory exceeds the allocated maximum storage size, the application may crash and this condition is
called 'Stack overflow'. The free memory region lying in between the stack and fixed memory area is
called 'heap'. Heap is the m~mory pool where storage for data is done dynamically as and when the
application demands. Heap is located immediately above the fixed memory area and it grows upward.
Any request for dynamic memory allocation by the program increases the size of heap (depending on
the a"'.ailability of free memory within heap) and the free memory request decrements the size of heap
(size of already occupied memory within the heap area). Heap can be viewed as a 'bank' in real life.
application, where customers can demand for loan. Depending on the availability of money, bank may --c
allot loan to the custofuer and customer re-pays the loan to the bank when he/she is through with his/her a
need. Bank uses the money repaid by a customer to allocate a loan to another customer-some kind of
rolling mechanism. 'C' language establishes the dynamic memory allocation technique through a set
of 'Memory management library.routines'. The most commonly used 'C' library functions for dynamic V
memory allocation are 'malloc', 'calloc', 'redlloc' and 'free'. The following sections illustrate the use of s
these memory allocation library routines for allocating and de-allocating (freeing) memorydynamically. t
mallocO mallocQ function allocates a block of memory dynamically. The mallocQ function reserves t
a block of memory of size specified as parameter to the function, in the heap memory and returns a
pointer of type void. This can be assigned to a pointer of any valid type. The general form of using mal-
locO function is given below. ·
pointer= {pointer_type *) malloc (no. of bytes);

where 'pointer' is a pointer of type 'pointer_type'. 'pointer_type' can be 'int', 'char', 'float' etc. mal-
locQ function returns a pointer of type· 'pointer_type' to a block of memory with size 'no. of bytes'. A
typical example is given below.
ptr~ (char*) m~lloc(50);

This instruction allocates 50 bytes (If there is 50 bytes of memory available in the heap area) and the
·address of the first byte of the allocated memory in the heap area is assigned to the pointer ptr of type
char. It should be noted that the mallocO function allocates only the requested number of bytes and it
 Embedded Firmware Design and Development

will not allocate memory automatically for the units of the pointer in use. For example, if the program-
mer wants to allocate memory for I 00 integers dynamically, the following code
x= ( ipt ,:;L m9-Uoc {-100) ;
will not allocate memory size for I 00 integers, instead it allocates memory for just I 00 bytes. In order
to make it reserving memory for 100 integer variables, the cqde should be re-written as

mallocO function can also be used for allocating memory for complex data types such as structure
pointers apart from the usual data types like 'int', 'char', 'float' _etc. mallocO allocates the requested
bytes of memory in heap in a continuous fashion and the allocation fails if there is no sufficient memory
available in continuous fashion for the requested number of bytes by the mallocO functions. The return
valu~ of mallocO will be NULL (0) if it fails. Hence the return value of mallocO should be checked to
ensure whether the memory allocation is successful before using the pointer returned by the mallocO
function.

Remember mallocO only allocates required bytes of memory and will not initialise the allocated
memory. The allocated memory contains random data.

callocO The library :function callocO allocates multiple blocks of storage bytes and initialises each
allocated byte to zero. Syntax of callocO function_ is illustrated below.

where 'pointer' is a pointer of type 'pointer_type'. 'pointer_type' can be 'int', 'char', 'float' etc. 'n'
stands for the number of blocks to be allocated and 'size of block' tells the size of bytes required per
block. The calloc(n, size of block) function allocates continuous memory for 'n' number of blocks with
'size of block' number of bytes per block and returns a pointer of type 'pointer_type' pointing to the first
byte of the allocated block of memory. A typical example is given below.
ptr= (char~) callee {50,1);

l
I
Above instruction allocates 50 contiguous blocks of memory each of size one byte in the heap mem-
ory and assign the address of the first byte of the allocated memory region to the character pointer 'ptr'.
Since mallocO is capable of allocating only fixed number of bytes in the heap area regardless of the
storage type, callocO can be used for overcomming this limitation as discussed below.
ptr= (int*) calloc(SO,sizeof(int));
This instruction allocates 50 blocks of memory, each block representing an integer variable and ini-
tialises the allocated memory to zero. Similar to the mallocO function, callocO also returns a 'NULL'
pointer if there is not enough space in the heap area for allocating storage for the requested number of
memory by the callocO function. He~ce it is advised to check the pointer to which the callocO assigns
 Introduction to Embedded Systems

the address of the first byte in the allocated memory area. If calloc() function fails, the return value will
be 'NULL' and the pointer also will be 'NULL'. Checking the pointer for 'NULL' immediately after
assigning with pointer returned by calloc() function avoids possible errors and application crash. r
Features provided by calloc() can be implemented using malloc() function as
poin,tEi'r :=. (.pqinter_:_type *) mall.oc (n * size of block);
memset (poibtel; 0, n *. size of b'iock) ;

For example

·.'.·\r:.·>/t]t;~ttiii}I;tt~~}~csi!~- 1,£s!~!:~!).?.~t)) ;·
The function memset (ptr, 0, n * size of block) sets the memory block of size (n * size of block) with
starting address pointed by 'ptr' ,· to zero.
freeO The 'C' memory management library function free'() is used for releasing or de~allocating the
memory allocated in the heap memory by malloc() or calloc() functions. If memory is allocated dynami-
cally, the programmer should release it if the dynamically allocated memory is no longer required for
any operation. Releasing the dynamically allocated memory makes it ready to use for other dynamic
allocations. The syntax of free() function is given below.
. free .(ptr);'

'ptr' is the valid pointer returned by the calloc() or malloc() function on dynami_c memory allocation.
Use of an invalid pointer with function.free() may result in the unexpected behaviour of the application.
Note: ....·.....
.l., The dynamic memory allocated using ma/loco or ca/loco functiQtlS $houldbe refe;s,¢d (d~al!Jc()tefl).

i!j!{:?!f~~~~\:!"~hich rejers:o)reeil~;;o~ sY,ft;:es~;;;~J~~;'.;~~;;;~~y~;;JJv

0

2.
3. lf 0 the,
the parameter 'to free . funr}tion is not a valid poinMr, behci:1doiir;11J~ be
,applicdtio{
unexpected. · .· · · .· · •· · · ·. ·

reallocO realloc() function is used for changing the size of allocated bytes in a dynamically allocated
memory block. You-may come across situations where the allocated memory is not sufficient to hold the
required data or it is surplus in terms of allocated memory bytes. Both of these situations are handled
using realloc() function. The realloc() function changes the size of the block of memory pointed to, by
the pointer parameter to the number of bytes specified by the·modified size parameter and it returns a
new pointer to the block. The pointer specified by the pointer parameter must have been created with
the malloc, calloc, or realloc subroutines and not been de-allocated with the free or realloc subroutines.
Function realloc() may shift the position of the already allocated block depending on the new size, with
preserving the contents of the already allocated block and returns a pointer pointing to the first byte of
the re-allocated memory block. realloc() returns a void pointer if there is sufficient memory available
for allocation, else return a 'NULL' pointer. Syntax of realloc is given below.
realloc (pointer, modified size~~

Example illnstrating the use of realloc() function is given below.

char -p;
p= (char*) malloc (10); //Allocate 10 bytes of memory lI
I.
I

I
 Embedded Firmware Design and Dev.elopment

11 p= realloc(p,15); //Change the allocation to 15 bytes

realloc(p,O) is same as free(p), provided 'p' is a valid pointer.

Summary

f
Embeddeq.fi~yVare Jnb~ dyy 19pe1 J,g•rtn}
7 ii~~
itie,~~lp o,(.an embe~ded gperat111!(~ystem or witho.
The nqfQS Sf1:Sedpnbedd~d firu;!ware exe6titi9n/tµijs~e tlilik¥ in'~n,mfutlte lq9p arid this appmach.i
~::"?' >
¢

'Supeflo<ipbits~d' bxecution) ;;:• . . ·.· . · .· . . . ·· "'f i re'.·' .•· • , . 'd• ., . •.... ·

h Lciw levefianguag~ (4;~s&mbl~ ~od~) orJiighL~vei lilligii~ge'lC;G;~:etc~J or.lini ofb~th are used ..
finriware devefopnient .. . .. . · ' •...•· .· ·. ... . . . . .. . \:: ·:
✓. In Assembly la11guage based 7desfgn;theipnnware is'oevelApecfusing theA~seinbly language Instructio~{~;t•:
1e · c::ificto .the target processor.1;he:Rssemblycode•is :converted t91u.gichine .• spec1fic cqcle:byanassembier."';,t;Ctii.:f,
1-
High Level langua:ge;based 'design,':the fimiw~tefs dev:eldped u;ing High LevelJaiiguage like 'C/G++>;ari~h .
)f is converted Jo machine specific code by a .ccinipiler or.crJ~s~co:inpiler: . . ... ,. ·
!C if~y Jvl,ixing o,ff\,eysepibJy ~~ tligfi, teyc;l l~nguageJan, lie dqµy jp thre¢;ways n~ety;·rnixing assembly routi!i ·..
/,,.)•··~ hjgh lev,~Hanguage: ljke 'C\-mixbg high lev~l l.an : .
0
. ?tions Hk~.\9''.nincticms with application~
0 ;, · in asse;nbly code and invoking assemblyfostj:119tioris·il1..1~~·fl'q111:the high,.le~i;fc9,Je: .· :· ·• ·. '
f:: :✓ ' Embedqed 'C' can pe eo11sid~red as .·~. SUQS,et :of.9ony~tiii9rfal 'C, .langu'age: Embedded C supports ;a,
1. ····'C'j11s~ctionI;
},:')/:.:~ ;.:,o.,,•''"-·'-f
arid.~corporates a.few ,t~rge(proci§§J)ts~¢~$.rfurictim}~finstructid~S.
•,''• :·•·,'-:;(i.:'.--~ ~"' _,.,,--,,-,_~
¥ '• \•·~,·:..-. <-'' . . " ,.J:,,_,,,,.:-.·'·-,•"
~<-·<•:?:•'i_ : ' ;.
The
,_
stan'da!a
.
·,
. . · library implementation is always tailoredJotl,ie targefprp~es?qr(controll~rJibrary;ftles in Embedded G••· .•. ·. . . ;
0

i
~;}:i,, Compil~r)s tootfop1atjye platfonn application geY;~loPh!~nt, .jJiere;s cross~compile~ is a tool for·cro$s.:pl~tf'li
'form
'. : t' . appifoation dev~lopnrent . .. . ' . '. .• . /" . -~:}\/
.. ✓ Embedded :<c• supports all the keywords, identifiers a[\d data typ~s, storage cl~sses, arithmetic <¥Id logicaL?P~f}; ·
tions, array and branching instructions supported by ;tand~rct"'C' ' . •.· ·• ., .. : . Y: .:.
a of
structtire is collection da:ta types. Arrays of structtftesireielpful in holding configuration data in en:ili~dd~d
applications. The biifieldfeature of structures helps in bit declaration and bif manipulation in embedded applica-
tions · ··· ·
✓ Pre-processor in 'C' is compiler/cross-compiler directives used by compiler/cross-compiler to filter the source
code before compilation/cross-compilation. Preprocessor directives falls into one of the categories: file inclusion,
te compile control and macro substitution
•d ✓ 'Read only' variable in embedded applications are represented with the keyword canst. Pointer to constant data
,y is a pointer which points to a data which is read only. A constant pointer is a pointer to a fixed memory location.
a Constant pointer to constant data is a pointer pointing to a fixed memory location which is read only
h ✓ A variable or memory location in embedded applic;i.tion, which is subject to asynchronous modification should
be declared with the qualifier volatile to prevent th~ compiler optimisation on the variable
s.
✓ A constant volatile pointer represents a Read only register (memory location) of a memory mapped device in
:h
embedded application
)f
✓ while(J) {};do { }while (]);for(,·;){} are examples for infinite loop setting instructions in embedded 'C'.
le ✓ The ISR contains the code for saving the cunent context, code for perfom1ing the operation corresponding to
the interrupt, code for retrieving the saved context. and code for infom1ing the processor thal the processing of
interrupt is completed
✓ Recursive Junction is a function which calls it repeatedly. Functions which can be shared safely with several
processes concurrently are called re-entrant function.
✓ Dyna,'nic memory allocation is the technique for allocating memory on a need basis for tasks. mallocQ, callocO,
realloc() and free() are the 'C' library routines for dynamic memory management
 Introduction to Embedded Systems

c• Keywords l
Super Loop Model An embedded.finnware design model which executes tasks in an infinite lop'p
at a predefined .order
Assembly Language Thehumanreadable n<;itatip•n:of'rnachine lan · a e'
Mac~ine Language Pro.ces.s
,-,, .,,,-_'•

Mn:emohlc·s·
·t\~,;eWf\~f '.
'ljtbra·ry
.ii!iki~.
HexFile:
' ~·-, ,

Iriline ,(\sseinJ:dy .
Elhbedd~d ('.. , . ·
-'· r···~:-, .,,

Compiler

CrossjCOillPi!er'
:' { '

pr
: ' A: ieltJSo ed
Function·Poin:ter. :· = . }:l[te~:{~j-
structure' :JJiJ~~1~$~(
. r~~f. >i2::~+ri::>i\ ·\:r:;;l, ,f>'>•,•,,. ,,, ··., xf'c:i,i,'\,;\
strucfore Pad~ing ·• • •c:The tipt_~f.:B:¥a,Pzjg~,$1~ t~.t,luc@~ el~~~µts·,in !Ill~i;g,9ry;1.n:,,
increased exe.cution sp~ed · .
union : A derive4 iorm of structure, whickallocates me~ory onlyioth~j:ne,mbe,rya:ri::<•
able of union requiring the maximum storage size on decl9-ring .a µnion van"··
able
Pre-processor A compiler/cross-co~piler directives used l;)y .compiler/ cross~compiler to filter
the source code before compilation/cross-compilation in ',C' language
Macro The 'C' pre-processor for creating portable inline code
const A keyword used in 'C' language for informing the compikr/cross-compiler that
the variable is constant. It represents a 'Read only' variable
Dynamic Memory Allocation The technique for allocating memory on a need basis at nm time
Stack The memory area for storing local variables, function parameters and function
return values and program counter, in the memory model for an applicatiorJ
task
Static l\lemory Area The memory area holding the program code, constant variables, static and glob-
al variables, in the memory model for an application/task
The free memory lying in between stack and static memory area, which is used
for dynamic memory allocation
 Embedded Firmware Design and Development

Objective Questions
1. Which of the following is a processor understandable language?
(a) Assembly language (b) Machine language (c) High level language
2. Assembly language is the human readable notation of?
(a) Machine language (b) High level language (c) None of these
3. Consider the following piece of assembly code

Here 'ORG' is a
(a) Pseudo-op (b) Label (c) Opcode (d) Operapd
4. Translation of assembly code to machine code is performed by the
(a) Assembler (b) Compiler (c) Linker (d) Locater
5. A cross-compiler converts an embedded 'C' program to
(a) The machine code corresponding to the processor of the PC used for application development
(b) The machine code corresponding to a processor which is different from the processor of the PC used for
application development
6. 'ptr' is an integer pointer.holding the address of !\fl integer variable say x which holds the value 10. Assume the
address of the integer variable x as 0xl2ff7c. What will be the output of the below piece of code? Assume the stor-
age size of integer is 4

(a) 0x12ff7c (b) 0x12ff7e (c) 0xl2ff84 (d) None

7. 'ptr' is a char pointer holding the address of a char variable say x which holds the value 10. Assume the address
of the char variable x as 0xl2ff7c. What will be the output of the below piece of code?
JNr1IZt the "~\id~~;f
printf ("Ox%x\h,,,
(a) 0xl2ff7c (b) 0x12ff7d (c) 0xl2ff80 (d) None
8. 'ptr' is a char pointer holding the address of a char variable say x which holds the value 10. Assume the address
of the char variable x as Ox 12ff7c. What will be the output of the below piece of code?
//Print the address hGlding by the pointer
("Ox%x\n", );

(a) 0xl2ff7c (b) 0x12ff7d (c) 0x12ff80 (d) None

9. 'ptrl' is a char pointer holding the address of the char variable say x which holds the value 10. 'ptr2' is a char
pointer holding the address ?f the char variable say y which holds the value 20. Assume the address of char vari-
able x as 0xl2ft7c and char variable y as 0x12ff78. What will be the output of the following piece of code?
//Print the address holding
,· ,.
•'·,'
by t4e pointer ~-;'

printf ( "%x\h", (ptr1+ptr2) T;

(a) 30 1 (b) 4 (c) Compile error (cannot add two pointers)
\
(d) 0x2\5fef4
 Introductio~ to Embedded Systems

I 0. 'ptr J' is a char pointer holding the address of the char variable say x which holds the value I 0. Assume the address
of char variable x as Oxl2ff7c. What will be the output of the following piece of code?
++*ptrl;
printf("%x\n", *ptrl);

(a) OxOa (b) OxOb (c) Oxl2ff7c (d) Oxl2ft7d

11. 'ptrl' is a char pointer holding the address of the char variable say x which holds the value 10. Assume the address
of char variable x as Oxl2ff7c. What will be the output of the following piece of code?

(~) OxOa (b) OxOb (c) Oxl2ff7c (d) Oxl2ff7d

12. 'ptrl' is a char pointer holding the address of the char variable say x which holds the value 10. Assume the address
of char variable x as Oxl2ft7c. What will be the output of the following piece of code?
*pt:.rl++;
pr:fr\tf("%x\n 1' , *ptri);

(a) OxOb (b) The contents of memory location Ox12ff7d (c) Ox12ft7c
(d) Oxl2ff7d
13. 'ptrl' is a char pointer holding the address of the char variable say x which holds the value 10. Assume the address
of char variable x as Oxl2ff7c. What will be the output of the following piece of code?
*ptrl++;
printf ("%x\nlf, ptrl);

(a) OxOb (b) The contents of memory location Oxl2ff7d (c) Oxl2ff7c
(d) Oxl2ft7d
14. Which of the following is the string termination character?
(a) '\n' (b) '\t' (c) '\O' (d) '\a'
15. What is the output of the following piece of code?

char narneJ6] = { 'H', 'E', 'L', 'L' ~ 'O',' \P'!Jf

printf("%d",strlen(name));
(a) 6 (b) 5 (c) 7 (d) None of the above
16. What is the output of the following piece of code?
char strl[] ="Hello"
char str2 [] "World!";
strl+= str2;
printf("%s\n",strl);
(a) Hello (b) Hello World! (c) Compile error (d) World!
17. What is the output of the following piece of code?
char strl "Hello world!";
char str2 "Hello World!n ;
int n;
n= stricmp(strl, str2);
printf("%d", n);
(a) l (b) O (c) -1
 Embedded Firmware Design and Development

18. What is the output of the following piece of code?

char strl[] =~Hello"

char str2[] = "Worldl";
strcpy(strl,str2};
printf ("%s\n", strl);

(a) Hello (b) Hello World! (c) Compile error (d) World!
19. What is the output of the following piece of code?

char strl(J = "Hello n

char .str.2[1, = \lWorld!;';
· s:t'iii = .,str2;
printf{"is\n'!, sttL).;
}(; (a) Hello (b) Hello World! (c) Compile error (d) World!
20. Consider the following structure declaration

typedef struct
.:.
.:,-.··
{
unsigned char comrrfandX/1:':i\romand to J:i~s·§··.,to device
uhsi9ped char~
sta ti.is};:[';;!
<. ~\-'.-~.-::- ·\:;,},
·-r-,:-f':•:~}.
t:µs'' ◊f? co:inmand
<:- _{,'l?:'. ,-·~_•;,· ~<
"i ~-:.:-
i=xecuticni
~-'_~:t. . ·J; _:. :._, ·" · ·
Byt.l;!s:_+'ci~~ ....,(_;.;. }{~?;i,. ·o; ~~tt2·s "'tO send
·• )-< --_ -- • • • : ·:::

un:signed _d1~r
.. unsigned char By,j:-e$Recteiv_¢d;} J /ijo .. of ''.l)ytEi!s rec:eived
} Irifo; : . · ·. . , ;'., ·~-:-:·::{ '.\};_J .. ;' . . " . . .: ,: __
Assuming the size of unsigned char as 1 byte, what will be the memory allocated for the structure?
(a) l byte (b) 2 bytes (c) 4 bytes (d) 0 bytes
21. Consider the following structure declaration

typedef struct

unsigned char hour; // command to pass to device

unsigned ch·ar minute; //status of command execution
unsigned char seconds; //No. of bytes lo send
)RTC Time;

Assuming the size of unsigned char as l byte, what will be the output of the following piece of code when com-
piled for Keil C5 l cross compiler

static volatile RTC Time xdata *current time (void xdata *) Ox7000;
void main()
{
unsigned char test;
test current time->minute;
printf("%d", test);

(a) 0x7000 (b) 0x7001 (c) Content of memory location 0x7000

(d) Content of memory location 0x700 l
 Introduction to Embedded Systems

22. Consider the following structure declaration 2

.Cypede"f;: . • . ·.
.·51r?J::j( 2

Assuming the size of unsigned char as 1 byte, what will be the output of the following piece of code when com-
piled for Keil CS I cross compiler

(a) 1 (b) 2 (c) Compile error (d) 0

23. Consider the following union definition

What will be the output of the following piece of code? Assume the storage size of int as 2 and unsigned char as
I

unsigned ch,ar t~st;

test sizeof' {:Lqt~ch:a.rr}":
prfntf (."%d", test);.

(a) 0 (b) 2 (c) 3 (d) 5

24. The default initialiser for a union with static storage is the default for
(a) The first member variable
(b) The last member variable
(c) The member variable with the highest storage requirement
25. Which of the following is (are) Tme about pre-processor directives?
(a) compiler/cross-compiler directives
(b) executable code is generated for pre-processor directives on compilation
(c) No executable code is generated for.pre-processor directives on compilation
(d) Start with# symbol (e) (a), (pJ and,(d) (t) (a), (c) and (d)
26. The 'C' pre-processor directive instruction always ends with a semicolon(;). State 'True' or 'False'
(a) True , (b) False
27. Which of the followingjs the file inclusion pre-processor directive?
(a) #define (b) #include (c) #ifdef (d) None of these
 Embedded Firmware Design and Development

28. Which of the following pre-processor directive is used for indicating the end of a block following #ifdef or
#else?
(a) #define (b) #undef (c) #endif (d) #ifndef
29. Which of the following preprocessor directive is used for coding macros?
(a) #ifdef (b) #define (c) #undef (d) #endif
30. What will be the output of the following piece of code?

(a) 0 (b) 2 (c) 9 (d) 8

31. The instruction

represents:
(a) Pointer to constant data (b) Constant pointer to data
(c) Constant pointer to constant data (d) None of these
32. The instruction

•~nsi.9h/:id 'ch~r* cons c x; ·

represents:
(a) Pointer to constant data (b) Constant pointer to data
(c) Constant pointer to constant data (d) None of these
33. The instruction

co.list unsigne:d char* Const x;'

represents:
(a) Pointer to constant data (b) Constant pointer to data
(c) Constant pointer to constant data (d) None of these
34. The instruction

volatile unsigned char* x;

represents:
(a) Volatile pointer to data (b) Pointer to volatile data
(c) Volatile pointer to constant data (d) None of these
35. The instmction

volatile canst unsigned char* x;

represents:
(a) Volatile pointer to data (b) Pointer to volatile data
(c) Pointer to constant volatile data (d) None of these
36. The constant volatile variable in Embedded application represents a
0

(a) Write only memory location/register (b) Read only memory location/register
(c) Read/Write memory location/register
 Introduction to Embedded Systems

37. What will be the output of the following piece of code? Assume the data bus width of the controller on which the
program is executed as 8 bits.

(a) 0x00 (b) 0x70 (c) 0x80 (d) 0xFF

38. The variable 'x' declared with the following code statement

will be stored in which section of the memory allocated to the program?

(a) Constant Data Memory (b) Heap Memory (c) Alterable Data Memory
(d) Stack Memory (e) Register 1
39. What will be the memory allocated on successful execution ofthe following memory allocation request? Assume
the size of int as 2 bytes
· lint ~ l .rnallot:Jl6'oL;
(a) 2 Bytes (b) 100 Bytes (c) 200 Bytes (d) 4 Bytes
40. Which of the following memory management routine is used for changing the size of allocated bytes in a dynami-
_cally allocated memory block
(a) mallocQ (b) reallocQ (c) callocQ (d) freeO

Review Questions
l. Explain the different 'embedded firmware design' approaches in detail
2. What is the difference between 'Super loop' based and 'OS' based embedded firmware design? Which one is the
better approach?
3. What is 'Assembly Language' Programming?
4. Explain the format of assembly language instruction
5. What is 'pseudo-ops'? What is the use of it in Assembly Language Programming?
6. Explain the various steps involved in the assembling of an assembly language program
7. What is relocatable code? Explain its significance in assembly programming
8. Explain 'library file' in assembly language context. What is the benefit of 'library file'?
9. What is absolute object file?
10. Explain the advantages of' Assembly language' based Embedded firmware development
11. Explain the limitations/drawbacks of 'Assembly language' based Embedded finnware development
12. What is the difference between compiler ahd cross-compiler?
13. Ex.plain the 'High Level language' based 'Embedded firmware' development technique
14. Explain the advantages of 'High Level language' based 'Embedded firmware' development
15. Give examples for situations demanding mixing of assembly with 'C'. Explain the techniques for mix1ng assembly
with 'C'. .
16. Give examples for situations demanding mixing of .iC' with assembly. Explain the techniques for mixing 'C' with
assembly.
 Embedded Firmware Design and Development

17. What is 'inline Assembly'? How is it different from mixing assembly language with 'C'?
e 18. What is 'pointer' in embedded C programming? Explain its role in embedded application development.
19. Explain the different arithmetic and relational operations supported by pointers
20. What is 'NULL' Pointer? Explain its significance in embedded C programming
21. Explain the similarities and differences between strings and character arrays
22. ·Exp lam functi6n in the Embedded C programming context. Explain the generic syntax of function declaration and
implementation
23. What is static function? What is the difference between static and global functions?
24. Explain the similarities and differences between functiqn prototype.and function declaration
25. What is function pointer? How is it related to function? Explain t4e use of function pointers
26. Explain structure in the 'Embedded C' programming context. Explain the significance of structure over normal
variables
27. Explain the declaration and initialisation of structure variables
28. Explain the different operations supported by structures
29. What is structure pointer? What is the advantage of using structure pointers?
30. Explain 'structure placement at absolute memory location' and its advantage in embedded application d,evelop-
ment. Will it be possible to place a stmcture at absolute memory location in desktop application development?
~
Explain
31. What is structure padding? What are the merits and demerits of structure padding?
32. What is bit field? How bit field is useful in variant data access?
33. Explain the use of offsetofO macro in structure operations.
34. What is union? What is the difference between union and structure?
35. Explain how union is useful in variant data access.
36. Explain the use of union in 'Embedded C' applications
37. What is pre-processor directive? How is a pre-processor directive instruction differentiated from normal program
code?
38. What are the different types of pre-processor directives available in 'Embedded C'? Explain them in detail
39. What is macro in 'Embedded C' programming?
40. What is the difference between macros and junctions?
41. What are the merits and drawbacks of macros?
42. Write a macro to multiply two numb.ers
... ~ 43 . Explain the different methods of 'constant data' declaration in 'Embedded C'. Explain the differences between the
methods.
44. Explain the difference between 'pointer to constant data' .and 'constant pointer to data' in 'Embedded C'
programming. Explain the syntax for declaring both.
45. What is constant pointer to constant data? Where is it used in embedded application development?
46. Explain the significance of 'volatile' type qualifier in Embedded C applications. Which all variables need to be
declared as 'volatile' variables in Embedded C application?
47. What is 'pointer to constant volatile data'? What is the syntax for defining a 'pointer to constant volatile data'?
What is its significance in embedded application development?
48. What is volatile pointer? Explain the usage of 'volatile pointer' in 'Embedded C' application
49. Explain the different techniques for delay generation in 'Embedded C' programming. What are the limitations of
delay programming for super loop based embedded applications?
50. Explain the different bit manipulation operations supported by 'Embedded C'
51. What is Interrupt? Explain its properties? What is its role in embedded application development?
52. What is Interrupt Vector Address and Interrupt Service Routine (ISR)? How are they related?
53. What is the difference between Interrupt Service Routine and Normal Service Routine?
54. Explain context switching, context saving and context retrieval in relation to Interrupts and Interrupt Service
Routine (ISR)
 Introduction to Embedded Systems

55. What all precautionary measures need to be implemented in an Interrupt Sei:vice Routine (ISR)?
56. What is 'recursion'? What is the difference between recursion and iteration? Which one is better?
57. What are the merits and drawbacks of 'recursion'?
58. What is 'reentrant' function? What is its significance in embedded applications development?
59. What is the difference between 'recursive' and 'reentrant' function?
60. Explain the different criteria that need to be strictly met by a function to consider it as 'reentrant' function.
61. What is the difference between Static and Dynamic memory allocation?
62.
63.
64.
Explain the different sections of a memory segment allocated to an application by the memory manager
Explain the different' Memory management library routines' supported by C
Explain the difference between the library functions malloc() and calloc() for dynamic memory allocation
I

~~ f1:ee,l);tr.a~t;Jr~9tienf hi
,tiort)~d 1e,hlrt1~.fitp,t~:µ~w; str}J~~.1,.
ttio~ ~d accep}s~tlitstring~\\Tith
. \,liaracte.r yafiableatmlt ..
/,\\~~}·,,... '.'\; : \;';~·~"_ :_~ <.: . ·vr-,\{,'..;.;
··•. '.al StµJJ~9compilert
ut and, explain t~.i: reaionie ::
'cprqg:am:t&t\oitlpleih~ntSit .. ¢!
.i hi91!)~,mi111qry;in~pp~citothe'CP1J. Tlie· .J:e " .· _•
1 ~no tfie
y,,io{~. < ·•... ,, diita#~$Jf:thifcbntroll~r status;fegi~t~r.of .·. · •· ·.••. ·... ·.· ~}86~( . •.• ..• ,,i
{~,r1wj1{~!s~;i1•e~~egM4:~·pr6gra~to·s~t,~it dearbh
Oand 7;~ftli;s~~sr,~~isf~~,6.,,.)d~~1Rer .m~~ '.
· · ". ttI~pp¢cl to ,t~e C;~U:•:Th~ status register ,of the device is memocy mapJfed f locaHoriQj8000: .... . . . ,Ja:'.:~µ:~ ·9;
. tli~'.fcii~trc,>1,er a.nij;the;.~t~tus register of*.5.'device is 8bit:w.ide. Th~.applic*fon sliqulliilltisb:at~iheiisage.:df'loif
. ·, riiimipulitioiio• . +'"' qns. . . . ·: ...· .··. . . · ·•.· · ·. · ·.·: ...... \::;>i•,\~·t;':T::·; i.C:,r,;'"·,t"~"·\ . :\ ?,L~~t'~;,G-··-
1
of
5.. · Write a·s,r,nail,~ .•, ¢dC program to t¢'st.the·status bif$;ofthY.:s,~i~gistena.nd reset·ififiti;1l:,1ofaFtjevice,
\\;hich'i's,meI11ofY)µapped t9 the. CPU. The stattfs regi~ter ofthe' d;~i~;1;;memory;Inapp,ed' at;Jop~tibniP¥io9b:
Tpe d1,1.!a'bus ofth~fO~~oll~r and the status iegister of the device is Soi(wide.<Th~iapplication,sholild'illtistfate
the usage of bitmanipulation operations.. .
an
6. Write 'Embedded C' program for Keil C51 cross-compiler for transmitting a string data through the serial port
of 8051 microcontroller:asper the followingrequirements ·
(a) Use structure to hold the communication parameters
(b) Use a structure array for holding the configurations corresponding to various baudrates (say 2400, 4800,
9600 and 195200)
(c) Write the code for sending a string to the serial port-as function. The main routine invokes this function with
the string to send. Use polling of Transmit Interrupt for ensuring the sending of a character
 ~~,,,,

f~})
\~
LEARNING OBJECTIVES

Learn the basics of an operating system and the need for an operating system
Learn the internals of Real-Time Operating System and the fundamentals oJRTOS based embedded firmware design
· Learnthe basic kernel services of an operating system · · ·
Learn about the classification of operating systems
Learn aboutthe different real-time kernels and the features th,at make a kernel Real Time
0

Learn about tasks, processes and threacfs in the operating system context
L~ ;Learh about the structure ofa process, the different states of a.process, process life cycle and process management
; ✓ Learn the concept of multithreading, thread standards and thread scheduling ·
. ✓ Understand the difference between multiprocessing and multitasking,
- . ✓ Learn about the different types of multitasking (Co-operative, Preemptive and Nqn-preemptive)
✓ Learn about the FCFS/FIFO, LCFS/UFO, SJF and priority,based task/process scheduling ·
Learn about the shortest remaining time (SRT), Round Robin and priority based preemptive task/process scheduling
r:./ Learn about the different Inter Process Communication (IPC) mechanisms used by tasks/process to communicate
and co:operate each other in a multitasking environment
✓ Learn the different types of shared memory techniques (Pipes, memory mapped object, etc.) for IPC
✓ Learn the different types of message passing techniques (Message queue, mailbox, signals, etc.) for IPC
· ✓ Learn the RPC based Inter Process Communication
✓ Learn the need for task synchronisation in a multitasking environment
✓ Learn the different issues related to the accessing of a shared resource by multiple processes concurrently
✓ Learn about 'Racing', 'Starvation', 'Livelock', 'Deadlock'., 'Dining Philosopher's Problem', 'Producer-Consumer/Bound-
ed Buffer Problem',. 'Readers-Writers Problem' and 'Priority Inversion'
✓ Learn about the 'Priority Inheritance' and 'Priority Ceiling' based Priority avoidance mechanisms
✓ Learn the need for task synchronisation and the different mechanisms for task synchronisation in a multitasking
environment
✓ Learn about mutual exclusion and the different policies for mutual exclusion implementation
✓ Learn about semaphores, different types of semaphores, mutex, critical section objects and events for task synchro-
nisation
✓ Learn about device drivers, their role in an operating system based embedded system design, the structure of a
device driver, and interrupt handling inside device drivers
✓ Understand the different functional and non-functional requirements that need to be addressed in the selection of
a Real-Time Operating System
 Introduction to Embedded Systems

In the previous· chapter, we discussed about the Super loop based task execution model for firmware
execution. The super loop executes the tasks sequentially in the order in which the tasks are listed
within the loop. Here every task is repeated at regular intervals and the task execution is non-real time.
As the number of task increases, the time intervals at which a task gets serviced also increases. If some
of the tasks involve waiting for external events or 1/0 device usage, the task execution time also gets
pushed off in accordance with the 'wait' time consumed by the task. The priority in which a task is to
be executed is fixed and is determined by the task placement within the loop,. in a super loop based ex-
ecution. This type of firmware execution is suited for embedded devices where response time for a task.
is not time critical. Typical examples are electronic toys and video gaming devices. Here any response
delay is acceptable and it will ·not create any operational issues or potential hazards. Whereas certain
applications demand time critical response to tasks/(;vents and any delay in the response may become
catastrophic. Flight Control systems, Air bag control and Anti Locking Brake (ABS) systems for ve-
hicles, Nuclear monitoring devices, etc. are typical examples of applications/devices demanding time
critical task response.
How the increasing need for time critical response for tasks/events is addressed in embedded applica-
tions? Well the answer is
1. Assign priority to tasks and execute the high priority task when the task is ready to execute. up
2. Dynamically change the priorities of tasks if required on a need basis. pre
3. Schedule the execution of tasks based on the priorities. in:
4. Switch the execution of task when a task is waiting for an external event or a system resource
including 1/0 device operation. 3.Pri
The introduction of operating system based firmware execution in embedded device_s can address wh
these needs to a greater extent. Mf

Fil
The operating system acts as a bridge between the user applications/tasks and the underlying system (sc
resources through a set of system functionalities and services. The OS manages the system resources filt
and makes them available to the user applications/tasks on a need basis. A normal computing system fik
is a collection of different I/0 subsystems, working, and storage memory. The primary functions of an res
operating system is
• Make the system con·venient to use
• Organise and manage the system resources efficiently and correctly
Figure 10.1 gives an insight into the basic components of an operating system and their interfaces
with rest of the world.

10.1.1 The Kernel so

as
The kernel is the core of the operating system and is responsible for managing the system resources and
the communication among the hardware and other system services. Kernel acts as the abstraction layer Il
between system resources and user applications. Kernel contains a set of system libraries and services. dil
For a general purpose OS, the kernel contains different services for handling the following. dii
AJ
Process Management Process management deals with managing the processes/tasks. Process man- th1
agement includes setting up the memory space for the proc~ss, loading the process's code into the mem- Sc
ory space, allocating system resources, scheduling and managing the .execution of the process, setting
"'
 Real-Time Operating System (RTOS) based Embedded System Design

<~?,f\:f~~F\'!~Tf~B,P<?k\{i.f:¥fi1[f- ~tt§Hf;f,f¾fh~~(;tt1F:,(:,:;}?\~:-
;kt '<ti,,#i2,#%;;
Application
programmmg
interface (API)

Device driver
interface

.. " up and managing the Process Control Block (PCB), Inter Process Communication and synchronisation,
process termination/deletion, etc. We will look into the description of process and process management
in a later section of this chapter.
,;;,.Primary Memory Management The term primary memory refers to the voJatile memory (RAM)
__ where processes are loaded and variables and shared data associated with each process are stored. The
"; Memory Management Unit (MMU) of the kernel is responsible for ·
· • Keeping track of which part of the memory area is currently used by which process
• Allocating and De-allocating memory space on a need basis (Dynamic memory allocation).
File System Management File is a collection of related information. A file could be a program
(source code or executable), text files, image files, word documents, audio/video files, etc. Each of these
files differ in the kind of information they hold and the way· in which the information is stored. The
file operation is a useful service provided by the OS. The file system management service of Kernel is
responsible for
• The creation, deletion and alteration of files
• Creation, deletion and alteration of directories
• Saving of files in the secondary storage memory (e.g. Hard disk storage)
• Providing automatic allocation of file space based on the amount of free space available
• Providing a flexible naming convention for the files
The various file system management operations are OS dependent. For example, the kernel of Micro-
soft® DOS OS supports a specific set of file system management operations and they are not the same
as the file system operations supported by UNIX Kernel.
I/0 System (Device) Management Kernel is responsible for routing the I/O requests coming from
different user applications to the appropriate I/O devices of the system. In a well-structured OS, the
direct accessing of I/O devices are not allowed and the access to them are provided through a set of
· ApB!ication Programming Interfaces (APis) exposed by the kernel. The kernel maintains a list of all
the I/O devices of the system. This list may be available in advance, at the time of building the kernel.
Some kernels, dynamically updates the list of available devices as and when a new device is installed
 Introduction to Embedded Systems

(e.g. Windows XP kernel keeps the list updated when a new plug 'n' play USB device is attached to Sm
the system). The service 'Device Manager' (Name may vary across different OS kernels) of the kernel ker
is responsible for handling all I/O device related operations. The kernel talks to the I/O device through me
a set of low-level systems calls, which are implemented in a service, called device drivers. The device der
drivers are specific to a device or a class of devices. The Device Manager is responsible for ma:
• Loading and unloading of device drivers pag .
• Exchanging information and the system specific control signals to and from the device anc
me
Secondary Storage Managem.ent The secgndary storage management deals wit~ managing the aHc
secondary storage memory dc;vices, if any, connected to the system. Secondary memory is used as the
backup medium for programs and data since the main memory is volatile. In most of the systems, the anc
j
secondary storage is kept in disks (Hard Disk). The secondary storage management service of kernel ow
deals with coc
• Disk storage allocation
• Disk scheduling (Time interval at which the disk is activated to backup data) 10.
• Free Disk space management , era
ker
Protection Systems Most of the modern operating systems are designed in such a way to support
multiple users with different levels of access permissions (e.g. Windows XP with user permissions like M<
'Administrator', 'Standard', 'Restricted', etc.). Protection deals with implementing the security policies He1
to restrict the access to both .user and. system resources by different applications or processes or users. nal
In_ multiuser supported operating systems, one user may not be allowed to view or modify the whole/ lo'"'
portions of another user's data or profile details. In addition, some application may not be granted with orf
permission to make use of some of the system resources. this kind of protection is provided by the so
protection services running within the kernel. mo
Interrupt Handler Kernel provides handler mechanism for all external/internal interrupts generated
by the. system.
These are some of the important services offered by the kernel of an operating system. It does not
mean that a kernel contains no more than components/services explained above. Depending on the type
of the operating system, a kernel. may contain lesser number of components/services or more number
of components/services. In addition to the components/services listed above, many operating systems
offer a number of add-on system components/services to the kernel. Network communication, network
management, user-interface graphics, timer services (delays, timeouts, etc.), error handler, database
management, etc. are examples for such components/services. Kernel exposes the interface to the vari-
ous kernel applications/services, hosted by kernel, to the user applications through a set of standard
Application Programming Interfaces (APis). User applications can avail these API calls to access the
various kernel application/services.
10.1.1.1 Kernel Space and User Space As we discussed in the earlier section, the applications/
services are classified into two categories, namely: user applications and kernel applications. The pro-
gram code corresponding to the kernel applications/services are kept' in a contiguous area (OS de-
pendent) of primary (working) memory and is protected from the un-authorised access by user pro-
grams/applications. The memory Space at which the kernel code is located is known as 'Kernel Space'. Mi
Similarly, all user applications are loaded to a specific area of primary memory and this memory area vie
is referred as 'User Space'. User space is the memory area where user applications are loaded and ex- as
ecuted. The partitioning of memory into kernel. and user space is purely Operating System dependent. tio1
 Real-Time Operating System (RTOS) based Embedded System Design

Some OS implements this kind of partitioning and protection·whereas some OS do not segregate the
kernel and user application code storage into two separate areas. In an operating system with virtual
memory support, the user applications are loaded irito its corresponding virtual memory space with
demand paging technique; Meaning, the entire code for the user application need not be loaded to the
· main (primary) memory at once; instead the user application code is split into different pages and these
. pages are loaded into and out of the main memory area on a need basis. The act ofloading the code into
...,and out of the main memory is termed as 'Swapping'. Swapping happens between the main (primary)
. ::memory and secondary storage memory. Each process run in its own virtual memory space and are not
;;/aHowed accessing the memory space corresponding to another processes, unless explicitly requested by
!\the process. Each process will have certain privilege levels on accessing the memory of other processes
.iand based on the privilege settings, processes can requ~st kernel-to map another process's memory to its
i'.'.~wn or share through some other mechanism. Most of the operating systems keep the kernel application
··.· code in main memory and it is not swapped out into the secQndary memory. ·
· J0.1.1.2 Monolithic Kernel and Microkernel As we know, the kernel forms the heart of an op-
·; •erating system. Different approaches are adopted for building an Operating System kernel. Based on the
kernel design, kernels can be classified into 'Monolithic' and 'Micro'.
·Monolithic Kernel In monolithic kernel architecture, all kernel services run in the kernel space.
Here all kernel modules run within the same memory space under a single kernel thread. The tight inter-
, nal integration of kernel modules in monolithic kernel architecture allows the effective utilisation of the .
low-level features of the underlying system. The major dr~wback of monolithic kernel is that any error
or failure in any one of the kernel modules leads to the crashing of the entire kernel application. LINUX,
SOLARIS, MS-DOS kernels are examples of monolithic kernel. The architecture representation of a
monolithic kernel is given in Fig. I 0.2.

Microkernel The microkernel design incorporates only the essential set o(Operating System ser-
vices into the kernel. The rest of the OperatinJ System services are implemented in programs known
as 'Servers' which runs in user space. This pr6vides a 1highly modular design and OS-neutral abstrac-
tion to the kernel. Memory management, process management, timer systems and interrupt handlers
 Introduction to Embedded Systems

are the essential services, which forms the part of dee

the microkernel. Mach, QNX, Minix 3 kernels are app
examples for microkernel. The architecture repre- by
sentation of a microkernel is shown in Fig. 10.3. me1
Microkernel based design approach offers the exa
following benefits
• Robustness: If a problem is encountered in JO.
any of the services, which runs as 'Server' Tin
application, the same can be reconfigured anc
and re-started without the need for re-start- bas
ing the entire· OS. Thus, this approach is
highly useful for systems, which demands
I
high 'availability'. Refer Chapter 3 to get
an understanding of 'availability'. Since the
services which run as 'Servers' are running
on a different memory space, the chances
of corruption of kernel services are ideally
zero. Ta,
• Configurability: Any services, which run as 'Server' application can be changed without the need tasl
to restart the whole system. This makes the system dynamically configurable. for
\ in£
TaJ
TaJ
Depending on the type of kernel and kernel services, purpose and type of computing systems where the
OS is deployed and the 'responsiveness to applications, Operating Systems are classified into different Tm
types. tirr
Tm
10.2.1 General Purpose Operating System (GPOS)
The operating systems, which are deployed in general computing systems, are referred as General Pur-
pose Operating Systems (GPOS). The kernel of such an OS is more generalised and it conta1ns all kinds
of services required for executing generic applications. General-purpose operating systems are often
quite non-deterministic in behaviour. Their services can inject random delays into application software
and may cause slow responsiveness of an application at unexpected times. GPOS are usually deployed
in computing systems where deterministic behaviour is not an important criterion. Personal Computer/ dif
Desktop system is a typical example for a system where GPOSs are deployed. Windows XP/MS-DOS TC
etc. are examples for General Purpose Operating Systems.

10.2.2 Real-Time Operating System (RTOS)

/ I '

There is no universal definition available for the term 'Real-Time' when it i's used in conjunction with
operating systems. What 'Real-Time' means in;Operating System context isst~ll a debatable topic and
there are many definitions available. In a broad sense, 'Real-Time' implies deterministic timing behav- Ta
iour. Deterministic timing behaviour in RT0S context means the OS services consumes only known and apJ
expected amounts of time regardless the number of services. A Real-Time Operating System or RTOS me
implements policie~ and rules concemint time-critical allocation of a system's resources. The RTOS bel
' ''
 Real-Time Operating System (RTOS) based Embedded System Design

decides which applications should run in which order and how much time needs to be allocated for each
application. Predictable performance is the hallmark of a well-designed RTOS. This is best achieved
by the consistent application of policies and rules. Policies guide the design of an RTOS. Rules imple-
ment those policies and resolve policy conflicts. Windows CE, QNX, VxWorks MicroC/0S-II, etc. are
examples of Real-Time Operating Systems (RTOS). '
10.2.2.l The Real-Time Kernel The kernel of a Real-Time Operating System is referred as Real.
Time kernel. In complement to the conventional OS kepiel, the Real-Time kernel is highly specialised
and it contains only the minimal set of services required for running the user applications/tasks. The
basic functions of a Real-Time kernel are listed below: ·
• Task/Process management
• Task/Process scheduling
• Task/Process synchronisation
• Error/Exception handling
• Memory management
• Interrupt handling
• Time management
Task/Process man.agement Deals with setting up the memory space for the tasks, loading the
task's code into the memory space, allocating system resources, setting up a Task Control Block (TCB)
for the task and task/process termination/deletion. A Task Control Block (TCB) is used for holding the
information corresponding to a task. TCB usually contains the following set of information.
Task JD: Task Identification Number
Task State: The current state of the task (e.g. State 'Ready' for a task which is ready to execute)\

Task Type: Task type. Indicates what is the type for this task. The task can be a hard real time or soft real
time or background task.
Task Priority: Task priority (e.g. Task priority= 1 for task with priority= 1)
Task Context Pointer: Context pointer. Pointer for context saving
Task Memo,y Pointers: Pointers to the code memory, data memory and stack memory for the task
Task System Resource Pointers: Pointers to system resources (semaphores, mutex, etc.) used by the task
Task Pointers: Pointers to other TCBs (TCBs for preceding, next and waiting tasks)
Other Parameters Other relevant task parameters
The parameters and implementation of the TCB is kernel dependent. The TCB parameters vary across
different kernels, based on the task management implementation. Task management service utilises the
TCB of a task in the following way
• Creates a TCB for a task on creating a task
• Delete/remove. the TCB of a task when the task is termina.ted or deleted
• Reads the TCB to get the state of a task
• Update the _TCB with updated parameters on need basis (e.g. on a context switch)
• Modify the TCB to change the priority of the task dynamically
Task/Process Scheduling Deals with sharing the 51/PU among various tasks/processes. A kernel
application called 'Scheduler' handles the task sch~duJing. Scheduler is nothing but an algorithm imple-
,.
I
mentation, which performs the efficient and optimal scheduling of tasks to provide a deterministic 1

behaviour. ,We will discuss the various types of scheduling- in a lat~r section of this qhapter.
I • /
 Introduction to Embedded Systems

la
Task/Process Synchronisation Deals with synchronising the concurrent access of a resource, lii
which is shared across multiple tasks and the communicat10n between various tasks. We will discuss
the various synchronisation techniques and inter task /process communication in a later section of this 11
chapter. T
tE
Error/Exception Handling Deals with registering and handling the errors occurred/exceptions It
raised during the execution of tasks. Insufficient memory, timeouts, deadlocks, deadline missing, bus l
error, divide by zero, unknown instruction execution, etc. are examples of errors/exceptions. Errors/Ex- St
ceptions can happen at the kernel level services or at task level. Deadlock is an example for kernel level n
exception, whereas timeout is an example for a task level exception. The OS kernel gives the informa- V
tion about the error in the form of a system call (API). GetLastErrorO API provided by Windows CE 1
RTOS is an example for such a system call. Watchdog timer is a mechanism for handling the timeouts ti
for tasks. Certain tasks may involve the waiting of external events from devices. These tasks will wait f ..
infinitely when the external device is not responding and the task will generate a hang-up behaviour. In r
order to avoid these types of scenarios, a proper timeout mechanism should be implemented. A watch- (

dog is normally used in such situations. The watchdog will be loaded with the maximum expected wait l
time for the event and if the event is not triggered within this wait time, the same is informed to the task I
and the task is timed out. If the event happens before the timeout, the watchdog is resetted.
Memory Management Compared to the General Purpose Operating Systems, the memory manage-
ment function of an RTOS kernel is slightly different. In general, the memory allocation time increases
depending on the size of the block of memory needs to be allocated and the state of the allocated
memory block (initialised memory block consumes more allocation time than un-initialised memory
block). Since predictable timing and deterministic behaviour are the primary focus of an RTOS, RTOS
achieves this by ·compromising the effectiveness of memory allocation. RTOS makes use of 'block'
based memory a1Jo6ation technique, instead of the usual dynamic memory allocation techniques used
by the GPOS~tos kernel uses blocks of fixed size of dynamic memory and the block is allocated for
a task on a need basis. The blocks are stored in a 'Free Buffer Queue'. To achieve predictable timing
and avoid the timing overheads, most of the RTOS kernels allow tasks to access any of the memory
blocks without any memory protection. RTOS kernels assume that the whole design is proven correct
andprotection is unnecessary. Some commercial RTOS kernels allow memory protection as optional
and the kernel enteis a fail-safe mode when an illegal memory access occurs.
· A few RTOS kernels implement Virtual Memoryt concept for memory allocation if the system sup-
ports secondary memory storage (like HDD and FLASH memory). In the 'block' based memory al-
location, a block of fixed memory is always allocated for tasks on need basis and it is taken as a unit.
Hence, there will not be any memory fragmentation issues. The memory allocation can be implemented
as constant functions and thereby it consumes fixed amount of time for memory allocation. This leaves
the deterministic behaviour of the RTOS kernel untouched. The 'block' memory concept avoids the
garbage collection overhead also. (We will explore this technique under the MicroC/OS-II kernel in a

t Virtual Memo1y is an imaginary memory supported by certain operating systems. Virtual memory expands the ~ddress space avail-
. able to a task beyond the actual physical memory (RAM) supported by the syitem. Virtual memory is implenwnted with the help of a
Memory Management Unit (MMU) and 'memory paging'. The program memory for a task can be viewed ast!iffereµt pages and the
page corresponding to'apiece of code 1that needs to be executed is loaded into the··main physical memory (RAM) .. When a memory page
is no longer required, it is moved.out to..syeondary storage memory and another page which contains the code snippet to be executed is
loaded into the main memory. This mem~ry movement technique is known as demand paging. The MMU handles the demand paging
a
and converts the virtual address of location in a page.to corresponding physical address in the RAM.
 Real-Time Operating System (RTOS) based Embedded System Design

latter chapter).The 'block' based memory aflocation achieves deterministic behaviour with the trade-of
limited choice of memory chunk size and suboptimal memory usage.
Interrupt Handling Deals with the handling of various types of interrupts. Interrupts provide Real-
Time behaviour to systems. Interrupts inform the processor that an external device or an associated
task requires immediate attention of the CPU. Interrupts can be either Synchronous or Asynchronous.
Interrupts which occurs in sync with the currently executing task is known as Synchronous interrupts.
Usually the software interrupts fall under the Synchronous Interrupt category. Divide by zero, memory
segmentation error, etc. are examples of synchronous interrupts. For synchronous interrupts, the inter-
rupt handler runs in the same context of the. interrupting task. Asynchronous. interrupts are interrupts,
which occurs at any point of execution of any task, and are not in sync with the currently executing task.
The interrupts generated by external devices (by asserting the interrupt line of the processor/controller
to which the interrupt line of the device is connected) connected to the processor/controller, timer over-
flow interrupts, serial data reception/ transmission interrupts, etc. are examples for asynchronous inter-
rupts. For asynchronous interrupts, the interrupt handler is usually written as separate task (Depends
on.OS kernel implementation) and it runs in a different context. Hence, a context switch happens while
handling the asynchronous interrupts. Priority levels can be assigned to the interrupts and each inter-
rupts can be enabled or disabled individually. Most of the RTOS kernel implements 'Nested Interrupts'
architecture. Interrupt nesting allows he pre-emption (interruption) of an Interrupt Service Routine
1
(ISR), servicing an interrupt, by a hig}t priority interrupt.
Time Management Accurate time management is essential for providing precise time reference for
all applications. The time reference to kernel is provided by a high-resolution Real-Time Clock (RTC)
hardware chip (hardware timer). The hardware timer is.programmed to interrupt the processor/control-
ler at a fixed rate. This timer interrupt is referred as 'Timer tick'. The 'Timer tick' is taken as the timing
reference by the kernel. The 'Timer tick' interval may vary depending on the hardware timer. Usually
the 'Timer tick' varies in the microseconds range. The time parameters for tasks are expressed as the
multiples of the 'Timer tick'.
The System time is updated based on the 'Timer tick'. If the System time register is 32 bits wide and the
'Timer tick' interval is 1 microsecond, the System time register will reset in
23 2 * 10-6/ (24 * 60 * 60) = 49700 Days = ~ 0.0497 Days 1.19 Hours
If the 'Timer tick' interval is 1 millisecond, the system time register will reset in
23 2 * IQ-3 I (24 * 60 * 60) 497 Days= 49.7 Days=~ 50 Days
The 'Timer tick' interrupt is handled by the 'Timer Interrupt' handler of kernel. The 'Timer tick' interrupt
can be utilised for implementing the following actions.
• Save the current context (Context of the currently executing task).
• Increment the System time register by one. Generate timing error and reset the System time regis-
ter if the timer tick count is greater than the maximum range available for System time register.
• Update the timers implemented in kernel (Increment or decrement the timer registers for each
timer depending on the count direction setting for each register. Increment registers with count di-
rection setting 'count up' and decrement registers with count direction setting 'count down').
• Activate the periodic tasks, which are in the idle state.
• Invoke the scheduler and schedule the tasks again based on the scheduling algorithm.
• Delete all the terminated tasks and their associated data structures (TCBs)
• Load the context for the first task in the ready queue. Due to the re-scheduling, the ready task might
be changed to a new one from the task, which was preempted by the 'Timer Interrupt' task. ~
 Introduction to Embedded Systems

i
Apart from these basic functions, some RTOS provide other functionalities also (Examples are file fo
management and network fq,hctions). Some RTOS kernel provides options for selecting the required e:J!
kernel functions at the time of building a kernel. The user can pick the required functions from the set 01
of available functions and compile the same to generate the kernel binary. Windows CE is a typical ex-
ample for such an RTOS. )Vhile building the target, the user can select the required components for the
kernel. i
A
10.2.2.2 Hard Real-Trne Real-Time Operating Systems that strictly adhere to the timing con- eJ
straints for a task is re\efed as 'Hard Real-Time' systems. A Hard Real-Time system must meet the 01
dea<;llines for a task .wit~o~t any slippage. Missing any deadline may produce catastrophic results for tt
Hard Real-Time System~, including permanent data lose and irrecoverable damages to the system/users.
Hard Real-Time systems emphasise the principle 'A.late answer is awrong answer'. A system can have
several such tasks and the key to their correct operation lies in scheduling them so that they meet their 1
time constraints. Air bag control systems and Anti-loc~ Brake Systems (ABS) of vehicles are typical (I
examples for Hard Real-Time Systems. The Air bag contt.ol system should be into action and deploy the C
air bags when the vehicle meets a severe accident. Ideally speaking, the time for triggering the air bag a
deployment task, when an accident is sensed by the Air bag control system, should be zero and the air t\
bags should be deployed exactly within the time frame, which is predefined for the air bag deployment p
task. Any delay in the deployment of the air bags makes the life of the passengers under threat. When
the air bag deployment task is triggered, the currently executing task must be pre-empted, the air bag
deployment task should be brought into execution, and the necessary 1/0 systems should be made read-
ily available for the air bag deployment task. To meet the strict deadline, the time between the air bag
deployment event triggering and start of the air bag deployment task execution should be minimum, ide-
ally zero. As a rule of thumb, Hard Real-Time Systems does not implement the virtual memory model
for handling the memory. This eliminates the delay in swapping in and out the code corresponding to the
task to and from the primary memory. In general, the presence· of Human in the loop (HITL) for tasks
introduces unexpected delays in the task execution. Most of the Hard Real-Time Systems are automatic
and does not contain a 'human in the loop'.
10.2.2.3 Soft Real-Time Real-Time Operating System that does not guarantee meeting deadlines,
but offer the best effort to meet the deadline are referred as 'Soft Real-Time' systems. Missing deadlines
for tasks are acceptable for a Soft Real-time system if the frequency of deadline missing is within the
compliance limit of the Quality of Service (QoS). A Soft Real-Time system emphasises the principle 'A
late answer is an acceptable answer, but it could have done bit fqster '. Soft Real-Time systems most of-
ten have a 'human in the loop (HITL) '. Automatic Teller Machine (ATM) is a typical example for Soft-
Real-Time System. If the ATM takes a few seconds more than the ideal operation time, nothing fatal
happens. An audio-video playback system is another example for 'soft Real-Time system. No potential
damage arises if a sample comes late by fraction of a second, for playback.

The tern1 'task' refers to something that needs to be done. In our day-to-day life, we are bound to the
execution of a number of tasks. The task can be tte· one assigned by our managers or the one assigned by
our professors/teachers or the one related to our personal or family l}eeds. In addition, we will nave an
order of priority and schedule/time line for executing these tasks. In the operating system context, a task
is defined as the program in execution and the related information maintail!,ed by the operating system
 Real-Time Operating System (RTOS)_based Embedded System Design

for the program. Task is also known as 'Job' in the operating system context. A program or part of it in
execution is also called a 'Process'. The terms 'Task', 'Job' and 'Process' refer to the same entity in the
operating system context and most often they are used interchangeably.

10.3.l Process
A 'Process' is a program, or part ofit, in execution. Pr.ocess is also known as an instance of a program in
execution. Multiple instances of the same program can execute simultaneously. A process requires vari-
ous system resources like CPU for executing the process; memory for storing the code corresponding to
the process and associated variables, I/O devices for information exchange, etc. A process is sequential
in execution.
10.3.1.1 The Structure of a Process The concept of 'Process' leads to concurrent execution
'(pseudo parallelism) of tasks and thereby the efficient utilisation of the CPU.and other system resources.
Concurrent execution is achieved through the sharing of CPU among the processes. A process mimics
a processor in properties and.holds a set of registers, process status, a Program Counter (PC) to point to
the next executable instruction of the process, a stack for holding the local variables associated with the
process and the code corresponding to the process. This can be visualised as shown in Fig. 10.4.

A process which inherits all the properties of the CPU can be considered as a virtual processor, await-
ing its tum to have its properties switched into the physical processor. When the process gets its tum, its
registers arid the program counter register becomes mapped to the pq-ysical registers of the CPU. From
a memoty perspective, the memory occuoied by the process is segregated into three regions, namely,
Stack memory, Data memory and Code memory (Fig. 10.5).
The 'Stack' memory holds all temporary data such as variables local to the process. Data memory
. holds all global data for the process. The code memory contains the program code (instructions) cor-
responding to the process. On loading a process into the main memory, a specific area of memory is
allocated for the process. The stack memory usually starts (OS Kernel implementation dep~!ldent) at
 · Introduction to Embedded Systems

the highest memory address from the memory area allocated for
re
the process. Say for example, the memory map of the memory area Stack Memory
01
allocated for the process is 2048 to 2100, the stack memory starts at - - -------- - -- V
address 2100 and grows downwards to accommodate the variables Stack memory grows
downwards C
local to the process.
' u
L0.3.1.2 Process States and State Transition The creation Data memory .1 'grows a:
of a process to its termination is not a single step operation. The upwards ti
process traverses through a series of states during its transition from -- -- - - - ---- -- I
the newly created state to the terminated state. The cycle through tl
which a process changes its state from 'newly created' to 'execu- 0
Data Memory
tion completed' is known as 'Process Life Cycle'. The various states r
through which a process traverses through during a Process Life ,
'
1
Cycle indicates. the current status of the process with respect to time ·~
Code Memory u
and also provides information on what it is allowed to do next. Fig-
ti
ure l 0.6 represents the various states associated with a proc(;!SS.
t
The state at which a process is being created is referred as
t
'Cr-eated State'. The Operating System recognises a process in the
'Created State' but no resources are allocated to
the process. The state, where a process is incept-
ed into the memory and awaiting .the processor 1
time for execution, is known as 'Ready State'.
At this stage, the process is placed in the 'Ready
Incepted into memory
list' queue maintained by the OS. The state where
in the source code instructions corresponding to
the process is being executed is called 'Running
State'. Running state is the state at which the '1
process execution happens. 'Blocked State/Wait l
State' refers to a state where a running process
is temporarily suspended from execution and
does not have immediate access to resources. The
blocked state might be invoked by various condi-
tions like: the process enters a wait state for an
event to occur (e.g. Waiting for user inputs such
as keyboard input) or waiting for getting access
to a shared resource (will be tiiscus~ed at a later
section of this chapter). A state where the process
completes its execution is known as 'Completed
State'. The transition of a process from one state
to another is known as 'State transition'. When a
process changes its state from Ready to running
or from running to blocked or terminated or from
blocked to running, the CPU allocation for the
process may also change.
It should be noted that the state representation
• for a process/task mentioned here is a generic rep-
 Real-Time Operating System (RTOS) based Embedded System Design

resentation. The states associated with a task may be known with a different name or there may be more
or less number of states than the one explained here under different OS kernel. For example, under
VxWorks' kernel, the tasks may be in either one or a specific combination of the states READY, PEND,
DELAY and SUSPEND. The PEND state represents a state where the task/process is blocked on wait-
ing for I/O or system resource. The DELAY state represents a state in which the task/process is sleeping
and the SUSPEND state represents a state where a task/process is temporarily suspended from execu-
tion and not available for execution. Under MicroC/OS-II kernel, the tasks may be in one of the states,
DORMANT, READY, RUNNING, WAITING or INTERRUPTED. The DORMANT state represents
the 'Created' state and WAITING state represents the state in which a process waits for shared resource
or I/O access. We will discuss about the states and state transition for tasks under VxWorks and uC/OS-
II kernel in a later chapter.
I 0.3..1.3 Process Management Process management deals with the creation of a process, setting
up the memory space for the process, loading the process's code into the memory space, allocating sys-
tem resources, setting up a Process Control Block (PCB) for the process and process termination/dele-
tion. For more details on Process Management, refer to the section 'Task/Process management' given
under the topic 'The Real-Time Kernel' of this chapter. ·

10.3.2 Threads
A thread is the primitive that can execute code.
A thread is a single sequential flow of control Stack M~mory
within a process. 'Thread' is also known as light- for Process
weight process. A process can have many threads
of execution. Different threads, wh~ch are part of
a process, share the same address space; meaning
. they share the data memory, code memory and
heap memory area. Threads maintain their own
thread status (CPU register values), Program
Counter (PC) and stack. The memory model for
a process and its associated threads are given in ( Fig.· I0.7) ~e~e>.~)'.',,~.~~~~Nl!>n .of ~.JJroce~s -.ndits
Fig. 10.7. associated:Threads .

I 0.3.2.1 The Concept of Multi threading A process/task in embedded application may be a com-
plex or lengthy one and it may contain various suboperations like getting input from I/O devices con-
nected to the processor, performing some internal calculations/operations, updating some I/O devices
etc. If all the subfunctions of a task are executed in sequence, the CPU utilisation may not be efficient.
For example, if the process is waiting for a user input, the CPU enters the wait state for the event, and
the process execution also enters a wait state. Instead of this single sequential execution of the whole
process, if the task/process is split into different threads carrying out the different subfunctionalities of
the process, the CPU can be effectively utilised and when the thread corresponding to the 1/0 opera-
tion enters the wait state, another threads which do not require the I/O event for their operation can be
switched into execution. This leads to more speedy ;execution of the process and the efficient utilisation
of the processor time and resources. The multithreaded architecture of a process can be better visualised
with the thread-process diagia!m, shown·in Fig. 1'0,8.\ · ·
: '
 Introduction to Embed~,ed Systems

PO
wit
Task/Process , dar
PO
Code ll!emory

ere
Stack ere
the
Re~isteys av
Thi
(ne
I
blo
ne,

Wr
5 ti

( Fig. 10.8) Process with multi-threads

If the process is split into multiple threads, which executes a portion of the process, there will be a
main thread and rest of the threads will be created within the main thread, Use of multiple threads to
execute a process brings the following advantage.
• Better memory utilisation. Multiple threads of the same process share the address space for data
memory. This also reduces the complexity of mter thread communication since variables can be
shared across the threads,
• Since the process is split into different threads, when one thread enters a wait state, the CPU can
be utilised by other threads of the process that do not require the event, which the other thread is
waiting, for processing. This speeds up the execution 9f the process.
• Efficient CPU utilisation. The CPU is engaged all time.
10.3.2.2 Thread Standards Thread standards deal with the different standards available for thread
creation and management. These standards are utilised by the operating systems for thread creation and
thread management. It is a set of thread class lipraries. The commonly available thread class libraries
are explained bel0w.
 Re~l-Time Operating System (RTOS) basedEmbedded System Design
',,,·1

POSIX Threads: POSIX stands for Portable Operating System Interface. The POSJX4 standard deals
with the Real-Tinie extensions and POSIX.4a standard deals with thread extensions. The POSIX stan-
dard library for thread creation and management is 'Pthreads'. 'Pthreads' library defines the set of
POSIX thread creation and management functions in 'C' language.
The primitive
·-· ,--~~i '. "':: \'

. ~;~ff/Df
<flij'.1 . ~at;guiuen
',,.,~· .,·: ',_... y'-'••f,:,1,,,1;. ;.. , ·;':.. ',(i_:?
-✓: ::\., • ,.

creates a new thread for running the function start_function. Here pthread_tis the handle to the newly
created thread and pthread_attr_tis the data type for holding the thread attributes. 'startJunction' is
the function the thread is going to execute and arguments is the arguments for 'startJunction' (lbs
a void * in the above example). On successful creation of a Pthread, pthread_create0 associates the
Thread Control Block (TCB) corresponding to the newly created thread to the variable of type pthread_t
(new _thread_JD in our example).
The primitive
;(- • _ .----, ,. ,. _, ,_ . _ ,_. : ·r_{,, _,:••~ '. __ ·_, ·)_ , _ '_ ,;;'.·..,;._ · :· ., •' ,,::c-,_·-. ,. . • _;;:;" :_i,,. ;.-.:•-,./fi,:·,.~i:
i4Jnt
t'l'l-t---·
pthrea¢
,
j6in (pthti:lad
:,,z::._i-•::,.... '"'··"\·-.
t n~w :j::h±ecl.d, void
'7"'.:_;._~.;:,t:·:;~ •. ~:_ ..... : . ::...~-:-:::,. ..
* thr,ea\f'.;i•~Ji:µ
_;.,. <.. ::-_-.-.··.:J-,,~f.1-.t.:r.

blocks the current thread and waits until the completion of the ,tlfread pointed by it (In this example
new_thread) i
All the PO SIX 'thread calls' returns an integer. A return value of zero indicates the success of the call.
It is always good to check the return value of each call.

Write a multithreaded application to print "Hello I'm in main thread" from the main thread and "Hello I'µi in new thread"
5 times each, using the pthread_createO and pthread_joinO PO SIX primitives.

~/~!!li::s~,•P!!Jlc<l;~i~[#,'.i;,{),mt>,~p~ ';OQ an.. PS "{!>•f1 :~Jf ~i l~

~;::iinclude, <pthtead,J1>
:'hnclude <stdlit,;. h>
•";Jin~lude <st"dio .h>
rBJ1** * **:* * * * *~t* * * * *** *.* *.* * ***·*fi:•** ** * ** *** ** * * * * ** ** * ** * * * *.* *** ** ** *
M7!New thread function fQr p'rinting "Hello I'm in new thre~d"
ff'yoid *new thre~d( void *th:r;1=ad_args)
/ '{ -

int i, j;
for( j= 0; j ,< 5; j++)
{
print£ {"H,ell9 I'm in n~.w thr~ad\n" );
/ /Wai tJ I for some ti.me. D~ 'ncithi~g ·
/ /The f91.iowLn9 lip.~ o):i ,9?Sl? ~an qe. replaced .with
I /OS suppo~te'd del?f flJ9cfJori lik~ sleep(}, ·delay· 0 etc,..
for( i= O; i 10000; .i+:i-);, < ..
l I .-,
return NULL;
 Introduction to Embedded Systems

Wi:
//*********************************************************fr********
//Start of main thread · ··
1

• '
Syi
1
int main'.( void ) of'
{
int i,

fin
Til
Tb
Ip:
lp1
ID1
. print£ ('~Hello I:m :in,main ,\hr~atj,~n'I, tT Al
//Wait:··f9r·som~:ftirne.' po nothi'n~f-·,· . ,_..... ·,fi-- .,.·
//The fblI~~1n~\rJk of. code c~n>bei~pi~i~cIWifh · lp
01
•. 4./'0S ,suppbr{eq,:q.e;tiy,.:fuh<itioh :l,ike>sleepJj {:tdE!ray ;etc,,,
fOrJ kt '(j} · fhc i 0000; i++ ) ; · · · fa
·-~- ·:. r .
i ( ·(pthread
. - join (tcb, NULL ) ).
-, ,-,
re
{ re
//Thread join failed pl
print£ ("Error in T.hread j.oln \n" · ) ; . 01
return -1;. tr
OJ
return 1;
o:
You can compile this application using the gee compiler. Examine the output to figure out the thread execution switch- tl
ing. The lines printed will give an idea of the order in which the thread execution is switched between. The pthreadjoin it
call forces the main thread to wait until the completion of the thread tcb, if the main thread finishes the execution first. p
The termination of a thread can happen in different ways. The thread can terminate either by completing its execu- tl
tion (natural tennination) or by a forced termination. In a natural termination, the thread completes its execution and
1
returns back to the main thread through a simple return or by executing the pthread_exitO call. Forced termination
can be achieved by the call pthread_cancelO or through the termination of the main thread with exit or exec functions.
tl
pthread_cancel() call is used by a thread to terminate another thread. f
pthread~exit() call is used by a thread to explicitly exit after it completes its work and is no longer required to exist. r
If the main thread finishes before the threads it has created, and exits with prhread_exit(}, the other threads continue to l
I
execute. Tf the main thread uses exit call to exit the thread, all threads created by the main thread is tenninated forcefully. L

Exiting a thread with the call pthread_exit() will not perform a cleanup. It will not close any files opened by the thread t
and files will remain in the open status even after the thread tenninates. Callingprhreadjoin at the end of the main thread
is the best way to achieve synchromsation and proper cleanup. The main thread, after finishing its task waits for the
completion of other threads, which were joined to it using the pth1-ead_join call. With a pthreadjoin call, the main thread
waits other threads, which were joined to it, and finally merges to the single main thread. If a new thread spawned by the
ma'.in thread is still not joined to the main thread, it will be counted against the system's maximum thread limit. Improper
cleanup will lead to the failure of new thread creation.
 Real-Time Operating System (RTOS) based Embedded System Design

Win32 Threads Win32 threads are the threads supported by various flavours of Windows Operating
Systems. The Win32 Application Programming Interface (Win32 API) libraries .provide the standard set
ofWin32 thread creation and m~nagementfun~tions. Win32 threads are created with the API
~) ,~,:·?lflrit · ·bet~i:f:,~;J\~:§j'~y!t!j~i, .l;t13t1:t~\,~'W?.:(¥t?
" .· e! L?T '. . ·• ·s'I?\~T ,p_O,I::1TT~;·lp$t. ;rt,Addi'e.,s$ 1 '; •.

~'~;tA:~n:ff;~;if, "LPn~9~_;·{~i~f~Zi{~;:i;~'~i·•·;'_:-. :_ :;;/:;:::{':', \if:~·::? .r. ·· :}·'.\~i1i&-i\: '.··:: ·;~:1:: • ·. ·

The parameter lpThreadAttributes defines the security attributes for .the thread and dwStackSize de-
fines the stack size for the thread. These·two parameters are not supported by the Windows CE Real-
Time Operating Systems and it should be kept as NULL and Orespectively in a CreateThread API Call.
The other parameters are
lpStartAddress: Pointer to the function which is to be executed by the thread.
lpParameter: Parameter specifying an applicatiop-defined value that is passed to the thread routine.
dwCreationFlags: Defines the state of the thread when it is created. Usually it is kept as O or CRE-
ATE_SUSPENDED implying the thread is created and kept at the suspended state.
lpThreadld: Pointer to a DWORD that receives the identifier for the thread.
On successful creation of the thread, Create Thread returns the handle to the thread and the thread identi-
fier.
TheAPIGetCurrentThread(void)returnsthehandleofthecurrentthreadandGetCurrentThreadld(void)
returns its ID. GetThreadPriority (HANDLE hThread) API returns an integer value representing the cur-
rent priority of the thread whose handle is passed as hThread. Threads are always created with normal
priority (THREAD_PRIORITY_NORMAL. Refer MSDN documentation for the different thread pri-
orities and their meaning). Set.ThreadPriority (HANDLE hThread, int nPriority) API is used for setting
the priority of a thread. The first parameter to this function represents the thread handle and the second
one the thread priority. .
For Win32 threads, the normal thread termination happens when an exception occurs in the thread,
or when the thread's execution is completed or when the primary thread or the process to which the
thread is associated is terminated. A thread can exit itself by calling the ExitThread (DWORD dwEx-
itCode) APL The parameter dwExitCode sets the exit code for thread termin~tion. Calling ExitThread
API frees all the resources utilised by the thread. The exit code of a thread can be checked by other
threads by calling the GetExitCodeThread (HANDLE hThread, LPDWORD lpExitCode). Terminate-
Thread (HANDLE hThread, DWORD dwExitCode) API is used for terminating a thread from another
thread. The handle hThread indicates which thread is to be terminated and ·awExitCode sets the exit code
for the thread. 'Phis API will not execute the thread termination and clean up code and may not free the
resources occupied by the thread. TerminateThread is a potentially dangerous call and it should not be
used in normal conditions as a mechanism for terminating a thread. Use this call only as a final choice.
SuspendThread(HANDLE hThread) API can be used for suspending a thread from execution provided
the handle hThread possesses THREAD_SUSPEND_RESUME access right. I{the SuspendThread API
call succeeds, the thread stops executing and increments its internal suspend count. The thread becomes
suspended if its suspend count is greater than zero. The SuspendThread function is primarily designed
for use by debuggers. One must be cautious in using this API for the reason it may cause deadlock condi-
tion if the thread is suspended at a stage where it acquired a mutex or shared resource and another thread
tries to access the same. The ResumeThread(HANDLE hThread) API is used for resuming a suspended
thread. The Resume Thread API checks the suspend count of the specified thread. A suspend count' of
 Introduction to Embedded Systems

zero indicates that the specified thread is not currently in the suspended mode. If the count is not zero,
the count is decremented by one and if the resulting count value is zero, the thread is resumed. The
API Sleep (DWORD dwMilliseconds) can be used for suspending a thread for the duration specified in tl
milliseconds by the Sleep function. The Sleep call is initiated by the thread. 0
\

t
Write a multithreaded application using Win32 APis to set up a counter in the main thread and secondary thread to count t
from Oto IO and print the counts from both the threads. Put a delay of 500 ms in betw~en the succ_essive printing in both s
the threads. e
s
· #include '~win.d9.ws .. hJ' ·
:·'>•:...,~· ;·~~,":.::,',_ \" ~,
·• ·· · · tc' ..,. ~-!',·· ,_
J;tl'.l<J).ude • stdio:.lt • ... , ."· . ;.:. . ;:'~.

i~~i~if;mf!Ii;lttt:~::::;::::·:
'i'.'•-i:.18?!3-r .+:z>: :-:::\< :} : ".:c ' '
,: ·. for(i.~0; i~,.,,l:0_;,f+i) •·
,.Lr . tL ;,:(,.~.-,~ ;.,,. : .,. ,..;:, ~i.:;
p:t·intf"("ExE'\c\ffJng_ chi Ia' '.'l'hr~aclf
.. Sie~p{s~o/} '
·•:•'.-' ';' '} ,,;·.,;·f:'·:·, .

:;;~)L'*~**i*"':'*, */f.:lti<.f't**'*,** **'*** **.'t: ******* *******'t'~"k*•*'-1:9'-l/,;;\li*:~ ::** "'***'t *

0

1/Pr:imaryi\threa~, .)·;,.
/ /-J<'* * * * * ** ** *** ** * /*t *t** * * * * ** *·* ** * ** ***** * * * * **~ *'* f<**-t-* **'* * *..*, *;t *"'l:ir ;\:'.
int;-JU~"in(int ;igG,.char* .argv[]):i ·• . . . •. ::_. .'., ,-::,
{
HANDLE hThreaa;
DWORD dwThreadID;
char i;
hThread=CreateThread(NULL,1000, (LPTHREAD_=::START_ROUTINE)
ChildThread, NULL, 0, &dwThrpadID);
if(hThread==NULL)
{
printf("Thread Creation Failed~nError No:
%d\n",GetLastError());
return l;

for(i=0;i<=l0;++i)
(
printf("Executing Main Thread: Counter= %d\nn,i);
Sleep(500J;
}
return 0;
 Real-Time Operating System (RTOS) based Embedded System Design

To execute this program, create a new Win32 Con-

sole Application using Microsoft Visual and add
the above piece of code to it and compile. The output
obtained on running this application on a :machine wit~
Windows XP operating system is given in I?ig. 10.9.
If you examine the output, you can see the switching
between main and child threads. The output need not be
the same always. The output is purely dependent on the
scheduling policies implemented by the windows op-
erating system for thread scheduling. You may get the
same output or a different output each time you run the
application .
. Java Threads Java threads are the threads
supported by Java programmirtg Language.
The java thread class 'Thread' is defined in the
package 'java. lang'. This package needs to be
imported for using the thread creation functions
supported by the Java thread class. There are
two ways of creating threads in Java: Either by
extending the base 'Thread' class or by implementing an interface. Extending the thread class allows
inheriting the methods and variables of the parent class (Thread class) only whereas interface allows a
way to achieve the requirements for a set of classes. The following piece of code illustrates the imple-
mentation of Java threads with extending the thread base class 'Thread'.

System:out.ptintln ("Hello from M'i:7Thread! ");

public static void main(String args[)}

{
(new MyThread()} .start();

. }

The above piece of code creates a new class MyThread by extending the base class Thread. It also
overrides the runO method inherited from the base class with its own runO method. The runO method
of MyThread implements all the task for the MyThread thread. The method startO moves the thread to
a pool of threads waiting for their tum to be picked up for execution by the scheduler. The thread is said
to be in the 'Ready' state at this stage. The scheduler picks the threads for execution from the pool based
on the thread priorities .
.g. . start();
. The output of the above piece of code when executed on Windows XP platform is given in
Fig. 10.10.
 Introduction to Embedded Systems ·

Invoking· the static method yieldO voluntarily give up the execution of the thread and the thread is
moved to the pool of threads waiting to get their tum for execution, i.e. the thread enters the 'Ready'
state:

The static method sleepO forces the thread to sleep for the duration mentioned by the sleep call, i.e.
the thread enters the 'Suspend' mode. Once the sleep period is expired, the thread is moved to the pool
of threads waiting to get their tum for execution, i.e. the thread enters the 'Ready' state. The method
sleepO only guarantees that the thread will sleep for the minimum_::.,--
period mentioned by the argument to
the call. It will not guarantee anything on tµe resume of the thread after the sleep period. It is dependent
on the scheduler.
f•hiTH':rei~La s"fe@p (too Ff;s ~~Eip ·,
Calling a thread Object's waitO method causes the thread object to wait. The thread will remain in the
',Wait' state until another thread invokes the notifyO or notifyAllO method of the thread object which is
waiting. The thread enters the 'Blocked' state when waiting for input from I/0 devices or waiting for
object lock in case of accessing shared resources. The thread is.moved to the 'Ready' state on receiving
the I/0 input or on acquiring the object lock. The thread enters the 'Finished/Dead' state on completion
of the task assigned to it or when the stopO method is explicitly invoked. The thread may also enter this
state if it is terminated by an umecoverable error condition.
For mpre information on Java threads, visit Sun Micro System's tutorial on Threads, available at
http://java.sun.com/tutorial/applet/overview/threads.html
Summary So far we discussed about the various thread classes available for creation and manage-
ment of threads in a multithreaded system in a General Purpose Operating System's perspective. From
an RTOS perspective, POSIX threads and Win32 threads are the most commonly used thread class
libraries for thread creation and management. Many non-standard, proprietary thread classes are also
used by some proprietary RIOS. Portable threads (Pth), a.very portable POSIX/ANSI-C based library
from GNU, may be the "next generation" threads library. Pth provides non-preemptive priority based
scheduling for multiple threads inside event driven applications. Visit http://www.gnu.org/software/pth/
for more details on GNU Portable threads.
10.3.2.3 Thread Pre-emption Thr~ad pre-emption is the.act of pre-empting the currently running
thread (stopping the currently running thread temporarily). Thread pre-emption ability is solely depen-
dent on the Operating System. rruead pre-emption is performed for sharing the CPU time among all
the threads. The execution switching among threads are known as 'Thread context switching'. Thread
context switching is dependent on the Operating system's scheduler and the type of the thread. When
we say 'Thread', it falls into any one of the following types.
 Real-Time Operating System (RTOS) based Embedded System Design

User Level Thread User level threads do not have kernel/Operating System support and they exist
solely in the rµnning process. Even if a process contains multiple user level threads, the OS treats it as
single thread and will not switch the execution among the different threads of it. It is the responsibility
of the process to schedule each thread as and when required. In summary, user level threads of a process
are non-preemptive at thread level from OS perspective.
Kernel/System Level Thread Kernel level threads are individual units of execution, which the OS
treats as separate threads. The OS interrupts the execution of the currently running kernel thread and
switches the execution to another kernel thread based on the scheduling policies implemented by the
OS. In summary kernel level threads are pre-emptive.
For user level threads, the execution switching (thread context switching) happens only when the
currently executing user level thread is voluntarily blocked. Hence, no OS intervention and system calls
are involved in the context switching of user level threads. This makes context switching of user level
threads very fast. On the other hand, kernel level threads involye lots of kernel overhead and involve
system calls for context switching. However, kernel threads maintain a clear layer _of abstraction and
allow threads to use system calls independently. There are many ways for binding user level threads
with system/kernel level threads. The following section gives an overview of various thread binding
models.
Many-to-One Model Here many user level threads are mapped to a single kernel thread. In this
model, the kernel treats all user level threads as single thread and the execution switching among the
user level threads happens when a currently executing user level thread voluntarily blocks itself or relin-
quishes the CPU. Solaris Green threads and GNU Portab_le Threads are examples for this. The 'PThread'
example given under the POSIX thread library section is an illustrative example for application with
Many-to-One thread model.
One-to-One Model In One-to-One model, each user level thread is bonded to a kernel/system level
thread. Windows XP/NT/2000 and Linux threads are examples for One-to-One thread models. The
modified 'PThread' example given under the 'Thread Pre-emption' section is an illustrative example for
application with One-to-One thread model.
Many-to-Many Model In this model many user level threads are allowed to be mappedto many
kernel threads. Windows NT/2000 with ThreadFibre package is an example for this.
10.3.2.4 Thread vis Process I hope, by now you got a reasonably good knowledge ofprocess and
threads. Now let us summarise the properties of process and threads.
 Introduction to Embedded Systems

The terms multiprocessing and multitasking are a little confusing and sounds alike. In the operating sys-
tem context multiprocessing describes the ability to execute multiple processes simultaneously. Systems
which are capable of performing multiprocessingr are.known as multiprocessor systems. Multiprocessor
systems possess multiple CPUs and can execute multiple processes simultaneously.
The ability of the operating system to have multiple programs in memory, wh1ch are ready for execu-
tion, is referred as multiprogramming. In a uniprocessor system, it 'is not possible to execute multiple
processes simultaneously. However, it is possible for a uniprocessor system to achieve some degree of
pseudo parallelism in the execution of multiple processes by switching the execution among ditferent
processes. The -ability of an operating system to hold multiple processes in memory l;lnd switch the
processor (CPU) from executing one process to another process is known as multitasking. Multitasking
creates the illusion of multiple tasks executing in parallel. Multitasking involves the switching of CPU
from executing one task to another. In an earlier section 'The Structure of a Process' of this chapter, we
learned that a Process is identical to the physical processor in the sense it has own register set which mir-
rors the CPU registers, stack and Program Counter (PC). Hence, a 'process' is considered as a' Virtual
processor', awaiting its tum.to have its properties switched into the physical processor. In a multitasking
environment, when task/process switching happens, the virtual processor (task/process) gets its proper-
ties converted into that of the physical processor. The switching of the virtual processor to physical pro-
cessor is controlled by the scheduler of the OS kernel. Whenever a CPU switching happens, the current
context of execution should be saved to retrieve it at a later point of time when the CPU executes the
process, which is interrupted currently due to execution switching. The context saving and retrieval is
essential for resuming a process exactly from the point where it was interrupted due to CPU switching.
The act of switching CPU among the processes or changing the current execution context is known as
'Context switching'. The act of saving the current context which contains the context details (Register
details, memory details, system resource usage details, execution details, etc.) for the currently running
process at the time of CPU switching is known as 'Context saving'. The process of retrieving the saved
context details for a process, which is going to be executed due to CPU switching, is known as 'Con-
text retrieval'. Multitasking involves 'Context switching' (Fig. 10.11 ), 'Context saving' and 'Context I
retrieval'. I
l
Toss juggling The skilful object manipulation game is a classic real world example for the multitask-
j
ing illusion. The juggler uses a number of objects (balls, rings, etc.) and throws them up and catches
C
them. At any point of time, he throws only one ball and catches only one per hand. However, the speed at
which he is switching the balls for throwing and catching creates the illusion, he is throwing and catch- t
t;
ing multiple balls or using more than two hands © simultaneously, to the spectators.
C
 Real-Time Operating System (RTOS) based Embedded System Design

I I
I m I
I <'\ B ii:I - Idle
I ij:::, ] S .I
I ~cc 0 ..= o 1 Running
I ~u m~ ~ I
I 21 ~~ gi I
I
I .a
~~
Cl)
E·~ll
·-
8
2
1
I
I
I
I
-~15
~ f g~j~
.i§u 1':1.
~ci.

0
-i;;
11..

'-' ~
b ... !I
I
:
I . i:l J.3 ·~ 5 I
Iv- s 0
~c.r I
: &l ~JI]~ijOo
I
I
I Clli:!,;5,,)JX: I
I ...:N ,..; I
II DI . of r
. execution
e ay m 1
I Process 2 happened I
r( due to 'Context ► 1
I Switching' I
Process 2

10.4.1 Types of Multitasking

As we discussed earlier, multitasking involveS-lhe switching of execution among multiple tasks. De-
pending on how the switching act is implemented, multitasking can be classified into different types.
The following section describes the various types of multitasking existing in the Operating System's
context.
10.4. I. I Co-operative Multitasking Co-operative multitasking is the most primitive form of
multitasking in which a task/process gets. a chance to execute only when the currently executing task/
process voluntarily relinquishes the CPU. In this method, any task/process can hold the CPU as much
time as it wants. Since this type of implementation involves the mercy of the tasks each other for getting
the CPU time for execution, it is known as co-operative multitasking. If the currel}tly executing task is

I non-cooperative, the other tasks may have to wait for a long time to get the CPU.····
I 0.4.1.2 ·Preemptive Multitasking Preemptive multitasking e~sures that every task/process gets a

l chance to execute. When and how much time a process gets is dependent on the implementation of the
preemptive scheduling. As the name indicates, in preemptive multitasking, the currently running task/
process is preempted to give a chance to other tasks/process to execute. The preemption of task may be
based on time slots or task/process priority.
10.4.1.3 Non-preemptive Multitasking. · Innon-preemptivemultitasking, the process/task, which is
currently given the CPU time, is allowed to execute until it terminates (enters the' Completed' state) or enters
the' Blocked/Wait' state, waiting for an I/0 or system resource. The co-operative and non-preemptive multi-
tasking differs in their behaviour when they are in the' Blocked/Wait' state. In co-operative multitasking, the
currently executing process/task need not relinquish the CPU when it enters the 'Blocked/Wait' state,
 Introduction to Embedded Systems

waiting for an 1/0, or a shared resource access or an event to occur whereas in non-preemptive multi-
tasking the currently executing task relinquishes the CPU when it waits for an I/0 or system resource
or an event to occur.

As we already discussed, multitasking involves the execution switching among the different tasks.
There should be some mechanism in place to share the CPU among the different tasks and to decide
which process/task is to be executed at a given point of time. Determining which task/process is to be
executed at a given point of time is known as task/process scheduling. Task scheduling forms the basis
of multitasking. Scheduling policies forms the guidelines for determining which task is to be executed
when. The scheduling policies are implemented in an algorithm and it is run by the kernel as a service.
The kernel service/application, which implements the scheduling algorithm, is known as 'Scheduler'.
The process scheduling decision may take place when a process switches its state to
1. 'Ready' state from 'Running' state
2. 'Blocked/Wait' state from 'Running' state
3. 'Ready' state from 'Blocked/Wait' state
4. 'Completed' state
A process switches to 'Ready' state from the 'Running' state when it is preempted. Hence, the type
of scheduling in scenario 1 is pre-emptive. When a high priority process in the 'Blocked/Wait' state
completes its I/0 and switches to the 'Ready' state, the scheduler picks it for execution if the scheduling
policy used is priority based preemptive. This is indicated by scenario 3. In preemptive/non-preemptive
multitasking, the process relinquishes the CPU when it enters the ''Blocked/Wait' state or the 'Com-
pleted' state and switching of the CPU happens at this stage. Scheduling under scenario 2 can be either
preemptive or non-preemptive. Scheduling under scenario 4 can be preemptive, non-preemptive or co-
operative.
The selection of a scheduling criterion/algorithm should consider the following factors:
CPU Utilisation: The scheduling algorithm should always make the CPU utilisation high. CPU utilisa-
tion is a direct measure of how much percentage of the CPU is being utilised.
Throughput: This gives an indication of the number of processes executed per unit of time. The
throughput for a good scheduler should always be higher.
Turnaround Time: It is the amount of time taken by a process for completing its execution. It includes
the time spent by the process for waiting for the main memory, time spent in the ready queue, time spent
on completing the I/0 operations, and the time spent in execution. The turnaround time should be a
minimal for a good scheduling algorithm.
Waiting Time: It is the amount of time spent by a process in the 'Ready' queue waiting to get the CPU
time for execution. The waiting time should be minimal for a good scheduling algorithm.
Response Time: It is the time elapsed between the submission of a process and the first response. For a
good scheduling algorithm, the response time should be as least as possible .
. .'.I'o . suwmari,se, .a, go9d,;~~h:c~9,ajiµg,~lgorit~?~~~ }ltgh.~fU.µtilisatioµ, ·miµhnum rum Around
, 1)me{1TA:'£);11~~~tht&1J,gh_put:~nd7:1i~§!i~sp~nse:ti}#e.•,: · >✓;::,, '': • • • ••• • • •

The Operating System maintains various queuest in connection with the CPU scheduling, and a pro-
cess passes through these queues during the course of its admittance to execution completion.
t Queue is a special kind of arrangement of a collection of objects. In the operating system context queue is considered as a buffer.
 Real-Time Operating System (RTOS) based Embedded System Design

The various queues maintained by OS in association with CPU scheduling are:

Job Queue: Job queue contains all the processes in the system
Ready Queue: Contains all the processes, which are ready for execution and waiting for CPU to get
their turn for execution. The Ready queue is empty when there is no process ready for running.
· Device Queue: Contains the set of processes, which are waiting for an I/O device.
A process migrates through all these queues during its journey from 'Admitted' to 'Completed' stage.
The following diagrammatic representation (Fig. 10.12) illustrates the transition of a process through
the various queues.

Job Queue

'"g
Admitted :,
O'
Run process to -ii>
completion

Ready Queue
t + - - - - Move preempted process to 'Ready' queue --8-1.

Move 110 Completed

Process to 'Ready' queue

Device
Manager

Device Queue

( Fig.10.12) Illustration of process transition through varii>us queues

·Based on the scheduling algorithm used, the scheduling can be classified into the following
categories.

10.S.l Non-preemptive Scheduling

Non-preemptive scheduling is employed in systems, which implement non-preemptive multitasking
model. In this scheduling type, the currently executing task/process is allowed to run until it terminates
or enters the 'Wait' state waiting for an I/O or system resource. The various types of non-preemptive
scheduling adopted in task/process scheduling are listed below.
10.5.1.1 First-Come-First-Served (FCFS)/ FIFO Scheduling As the name indicates, the First-
Come-First-Served (FCFS) scheduling algorithm allocates CPU time to the processes based on the
 Introduction to Embedded Systems

order in which they enter the 'Ready' queue. The first entered process is serviced first. It is same as any
real world application where queue systems are used; e.g. Ticketing reservation system where people
need to stand in a queue and the first person standing in the queue is serviced first. FCFS scheduling is
also known as First In Eirst Out (FIFO) where the process which is put first into the 'Ready' queue is
serviced first.

Three-processes with process IDs Pl, P2, P3 with estimated completion time 10, 5, 7 milliseconds respectivet}enters the
ready queue together in the order P1, P2, P3. Calculate the waiting time and Turn Around Time (TAT) for each process
and the average waiting time and Tum Around Time (As~uming there is no 1/0 waiting for the processes).
The sequence of executfon of the processes by the CPU is represented as
\

0 15 22
-◄---10---►-◄-5 ►◄ 7--►•

Assuming the CPU is readily available at the time of arrival of Pl, P1 starts executing without any waiting in the 'Ready'
queue. Hence the waiting time for Pl is zero. The waiting time for all processes are given as
Waiting Time for Pl = 0 ms (Pl starts executing first).
Waiting Time for P2 lOms (P2 starts executing after completing fl)
Waiting Time for P3 = 15 ms (P3 starts executing after completing Pl and P2)
Average waiting time = (Waiting time for all processes}/ No. of Processes
= (Waiting time for (Pl +P2+P3)) / 3
(O+ 1O+ 15)/3 = 25/3
= 8.33 milliseconds
Turn Around Time (TAT) for P1 = 10 ms (Time spent in Ready Queue+ Execution Time)
Tum Around Time (TAT) for P2 15 ms (-Do-)
Tum Around Time (TAT) for P3 22 ms . (-Do-)
Average Tum Around Time (Tum Around Time for all processes)/ No. of Processes
= (Tum Around Time for (Pl +P2+P3)) / 3
=(10+15+22)/3 = 47/3
= 1"5.66 milliseconds
Average Tum Around Time (TAT) is the sum of average waiting time and average execution time.
Average Execution Time (Execution time for all processes)/No. of processes
= (Execution time for (Pl +P2+P3))/3
(10+5+7)/3 22/3
= 7.33
Average Tum Around Time Average waiting time+ Average execution time
8.33.+ 7.33 //
= 15.66 milliseconds

i
 Real-Time Operating System (RTOS) based Embedded System Design

.~j~PAe:.i::,
Calculate the waiting time and Tum Around Time (TAT) for each process and the Average waiting time and Tum Around
Time (Assuming there is no 1/0 waiting for the processes) for th~ above example if the process enters the 'Ready' queue
together in the order P2, Pl, P3.
The sequence of execution of the processes by the CPU is represented as

0 5 15 22
'4-5--- ...
► ◄1-----10----
►◄'
◄1---7---1►•
Assuming the CPU is readily available at the time ·of arrival ~f P2, P2 starts executing without any waiting in the 'Ready' ·
queue. Hence the waiting time for P2 is zero. The waiting time for all processes is given as ·
Waiting Time for P2 = 0 ms (P2 starts executing first)
Waiting Time for Pl 5 ms (Pl starts executing after completing P2)
Waiting Time for P3 15 ms (P3 starts executing after completing P2 and P 1)
Average waiting time . (Waiting time for all processes) / No. of Processes
= (Waiting time for (P2+Pl+P3)) / 3
= (0+5+ 15)/3 = 20/3
6.66 milliseconds
Tum Around Time (TAT) for P2 = 5 ms (Time spent in Ready"Queue + Execution Time)
Tum Around Time (TAT) for Pl 15 ms (-Po-)
Tum Around Time (TAT) for P3 = 22 ms (-Do-)
Average Tum Around Time = (Turn Around Time for all processes) / No. of Processes
(Tui:nAround Time for (P2+Pl+P3)) / 3
= (5+ 15+22)/3 = 42/3
= 14 milliseconds
The Average waiting time and Tum Around Time (TAT) depends on the order in which the processes enter the 'Ready.;
queue, regardless there estimated completion time.
From the above two examples it is dear that the Average waiting time and Tum Around Time im-
prove if the process with shortest execution completion time is scheduled first.
The major drawback of FCFS algorithm is that it favours monopoly of process. A process, which
does not contain any l/O operation, continues its execution until it finishes its task. If the process con-
tains any l/O operation, the CPU is relinquished by the process. In general, FCFS favours CPU hound
processes and l/O bound processes may have to wait until the completion of CPU boµnd process, if the
currently executing process is a CPU bound process. This leads to poor device utilisation. The average
waiting time is not minimal for FCFS scheduling algorithm.
10.5.1.2 Last-Come-First Served (LCFS)ILIFO Scheduling The Last-Come-First Served
(LCFS) scheduling algorithm also allocates CPU time to the processes based on the order in which
they are entered in the 'Ready' queue. The last entered process is serviced first. LCFS scheduling is
also known as Last In First Out (LIFO) where the process, which is put last into the 'Ready' queue, is
serviced first.

,~,;,., . .\ 1 · l
.~~~mp;e •·
Three processes with process IDs Pl, P2, P3 with estimated completion time 10, 5, 7 milliseconds respectively enters the
•ready queue together in the order PJ, P2, P3 (Assume only Pl is present in the 'Ready' queue when the scheduler picks
 Introduction to Embedded Systems

it up and P2, P3 entered 'Ready' queue after-that). Now a new process P4 with estimated completion time 6 ms enters
the 'Ready' queue after 5 ms of scheduling P 1. Calculate the waiting time and Turn Around Time (TAT) for each process
and the Average waiting time and Turn Around Time (Assuming there is no I/0 waiting for the processes).Assume all the
processes contain only CPU operation and no I/0' operations are involved.
Initially there is only Pl available in t\}e Ready queue and the scheduling sequence will be Pl, P3, P2. P4 enters the
queue during the execution of Pl and becomes the last process entered the 'Ready' queue. Now the order of execution
changes to Pl, P4, P3, and P2 as given below.
1
1
\

0
10
10
6
16
7
23
5-+
28 ''
► ◄ ►◄ ►◄ }

The waiting time for all the processes is given as

Waiting Time for Pl = 0 ms (Pl starts executing first)
Waiting Time for P4 = 5 ms (P4 starts,executing after completing Pl. But P4 arrived after 5 ms of execution of P 1. Hence
its waiting time = Execution start time - Arrival Time = 10 5 = 5) 1
Waiting Time for P3 16 ms (P3 starts executing after completing P 1 and P4) 1
Waiting Time for P2 23 ms (P2 starts executing after completing Pl, P4 and P3) 1
Average waiting time = (Waiting time for all processes)/ No. of Processes }

= (Waiting time for (Pl +P4+P3+P2)) / 4

= (O + 5 + 16 + 23)/4 = 44/4
11 milliseconds
Turn Around Time (TAT) for Pl 10 ms (Time spent in Ready Queue + Execution Time) p
Turn Around Time (TAT) for P4 = 11 ms (Time spent in Ready Queue + Execution Time = (Execution Start Time 1
-Arrival Time)+ Estimated Execution Time= (10 5) + 6 = 5 + 6)
Turn Around Time (TAT) for P3 = 23 ms (Time spent in Ready Queue+ Execution Time)
Turn Around Time (TAT) for P2 = 28 ms (Time spent in Ready Queue + Execution Time)
Average Turn Around Time = (Turn Around Time for all processes)/ No. of Processes
= (Turn Around Time for (Pl +P4+P3+P2)) / 4
(10+11+23+28)/4 = 72/4 F
18 milliseconds 11

LCFS scheduling is not optimal and it also possesses the same drawback as that of FCFS algorithm.
10. 5.1. 3 Shortest Job First (S]F) Scheduling Shortest Job First (SJF) scheduling algorithm 's01ts (
the 'Ready' queue' each time a process relinquishes the CPU (either the process terminates or enters C
the 'Wait' state waiting for l/O or system resource) to pick the process with shortest (least) estimated 1
completion/run time. In SJF, the process with the shortest estimated run time is scheduled first, followed 0
by the next shortest process, and so on.
p
fi
[,Example 1 )
Three processes with process IDs Pl, P2, P3 with estimated completion time 10, 5, 7 milliseconds respectively enters the ti
ready queue together. Calculate the waiting time and Turn Around Time (TAT) for each process and the Average waiting it
time and Tum Around Time (Assuming there is no I/0 waiting for the processes) in SJF algorithm. "
,ti"
The scheduler sorts the 'Ready' queue based on the shortest estimated completion time and schedules the process with
C
the least estimated completion time first and the next least one as second, and so on. The order 1n which the processes are
scheduled for.execution is represented as q
a:
 Real-Time Operating System (RTOS) based Embedded System Design

0 5 12 22
,.__5 ►◄ 1--►~◄---10---
►

The estimated execution time of P2 is the least (5 ms) followed by P3 (7 ms) and Pl (IO ms).
The waiting time for all process~s are given.as
Waiting Time for P2 = 0 ms (P2 starts exe~uting first)
Waiting Time for P3 5 ms (P3 starts executing after completing P2)
Waiting Time for Pl = 12 ms (Pl starts execl.!ting after completing P2 and P3)
Average waiting time = (Waiting time for all processes)/ No. of Processes
(Waiting time for (P2+P3+Pl)) / 3
= (0+5+ 12)/3 = 17/3
5.66 milliseconds
Turn Around Time (TAT) for P2 = 5 ms (Time spent in Ready Queue + Execution Time)
Tum Around Time (TAT) forP3 12 ms (-Do-)
Turn Around Time (TAT) for PI = 22 ms (-Do-)
Average Tum Around Time (Tum Around Time for all processes)/ No. of Processes
= (Tum Around Time for (P2+P3+Pl)) / 3
(5+12+22)/3 = 39/3
= 13 milliseconds
Average Tum Around Time (TAT) is the sum of average waiting time and average execution time.
The average Execution time (Execution time for all processes)/No. of processes
= (Execution time for (Pl +P2+P3))/3
(10+5+7)/3 =1113 = 7.33
Average Tum Around Time =Average Waiting time+ Average Execution time
= 5.66 + 7.33
13 milliseconds
From this example, it is clear that the average waiting time and tum around time is much improved with the SJF schedul-
ing for the same processes when compared to the FCFS algorithm.

CalciJla.te the waiting time and Tum Around Time (TAT) for each process and the Average waiting time and Tum Around
Time for the above example if a new process P4 with estimated completion time 2 ms enters the 'Ready' queue after 2 ms
of execution of P2. Assume all the processes contain only CPU operation and no 1/0 operations are involved.
At the beginning, there are only three processes (Pl, P2 and P3) available in the 'Ready' queue and the SJF scheduler
picks up the process with the least execution completion time (In this example P2 with execution completion time 5 ms)
for scheduling. The execution sequence diagram for this is 'same as that of Example 1.
Now process P4 with estimated execution completion time 2 ms enters the 'Ready' queue after 2 ms of start of execu-
tion of P2. Since the SJF algorithm is non-preemptive and process P2 does not contain any I/0 operations, P2 continues
its execution. After 5 ms of scheduling, P2 terminates and now the scheduler again sorts the 'Ready' queue for process
with least execution completion time. Since the execution completion time for P4 (2 ms) is less than that of P3 (7 ms),
which was supposed to be run after the completion of P2 as per the 'Ready' queue available at the beginning of execu-
•tion scheduling, P4 is picked up for executing. Due to the arrival of the process P4 with execution time 2 ms, the 'Ready'
queue is re-sorted in the order P2, P4, P3, Pl. At the beginning it was P2, P3, Pl. The execution sequence now changes
as per the following diagram
 Introduction to Embedded Systems

tr
tl

0 5 7 14 24
+- 5 _____...,. ◄ 2•►•◄-- 7---►◄◄--- 10 ---►•
T
The waiting time for all the processes are given as 2
Waiting time for P2 0 ms (P2 starts executing first) T
Waiting time for P4 3 ms (P4 starts .executing after completing P2. But P4 arrived after 2 ms of execution of P2. Hence II
its waiting time Execution start time Arrival Time = 5 2 3)
Waiting time for P3 = 7 ms (P3 starts executing after completing P2 and P4)
Waiting time for Pl= 14 ms (Pl starts executing after completing P2, P4 and P3) "'ir
Average waiting time= (Waiting time for all processes)/ No. of Processes
(Waiting time for (P2+P4+P3+Pl )) I 4 .
= (0 + 3 + 7 + 14)/4 = 24/4
= 6 milliseconds
Tum Around Time (TAT) for P2 5 ms (Time spent in Ready Queue + Execution Time)
Tum Around Time (TAT) for P4 5 ms (Time spent in Ready Queue + Execution Time = (Execution Start Time
-Arrival Time)+ Estimated Execution Time= (5 -2) + 2 3 + 2)
Turn Around Time (TAT) for P3 = 14 ms (Time spent in Ready Queue + Execution Time) T
Turn Around Time (TAT) for P 1 = 24 ms (Time spent in Ready Queue + Execution Time) 'V
Average Turn Around Time (Tum Around Time for all Processes)/ No. of Processes V
= (Tum Around Time for (P2+P4+P3+Pl )) / 4 V
= (5+5+ 14+24)/4 = 48/4 A
= 12 milliseconds / ·
The average waiting time for a given set of process is mihimal in SJF scheduling and so it is optimal
compared to other non-preemptive scheduling like FCFS. The major drawback ofSJF algorithm is that
a process whose estimated execution completion time is high may not get a chance to execute if more T
and more processes with least estimated execution time filters the 'Ready' queue before the process T
with longest estimated execution time started its executiom (In non-preemptive SJF ). This condition is T
J,
known as 'Starvation'. Another drawback of SJF is that it is difficult to know in advance the next short-
est proc.es_s in the 'Ready' queue for scheduling since new processes with different estimated execution
time keep entering the 'Ready' queue at any point of time.
10. 5.1. 4 Priority Based Scheduling The Tum Around Time (TAT) and waiting time for processes
in non-preemptive scheduling varies with the type of scheduling algorithm. Priority based non-preemptive
scheduling algorithm ensures that a process with high priority is serviced at the earliest compared to other
(
low priority processes in the 'Ready' queue. The priority of a task/process c~n be indicated throµgh various C
mechanisms. The Shortest Job First (SJF) algorithm can be viewed as a priority based scheduling where each 1
q
task_ is prioritised in th~ or1~r ~f the_ ti~e ~equired to ~omplete the task. The l~w~r the t~m~ re~uired f~r ~om- ii
pletmg a process the h1gh1ec\•~ its pnonty m SJF algonthm. Another way of pnonty ass1gmng 1s associatmg a
priority to the task/process dph~ time of creation of the task/process. The priority is a number ranging from 0
r
to the maximum priority supp~rted by the OS. The maximum level of priority i$ OS dihendent. For Exam~le, d
Windows CE supports 256 levels of priority (0 to 255 priority. numbers). While creati~~the process/task, the
\ r
priority can be assigned to it. The priority number associated with a task/process is the direct indication of its f
priority. The priority variation from high to low is represented by numbers from Oto the maximum priority or r
by numbers from maximum priority to 0. For Windows CE operating system a priority numbet Oindicates the
highest priority and 255 indicates the lowest priority. This convention need not be universal and it depends on
 Real-Time Operating System (RTOS) based Embedded System Design

the kernel level implementation of the priority structure. The non-preemptive priority based scheduler sorts
the 'Ready' queue based on priority and picks the process with the highest level of priority for execution.

Three processes with process IDs Pl, P2, P3 with estimated completion time 10, 5, 7 milliseconds and priorities 0, 3,
2 ~0-highest priority, 3-lowest priority) respectively enters the ready queue together. Calculate the waiting time and
Turn Around Time (TAT) for each process and the Average waiting time and Tum Around Time (Assuming there is no
:e I/0 waiting for the processes) in priority based scheduling algorithm.
' The scheduler sorts the 'Ready' queue b~sed on the priority and schedules the process with the highest priority (Pl
with priority number 0) first and the next high priority process (P3 with priority number 2) as second, and so on. The order
in which the processes are scheduled for execution is represented as

0 10 17 22
te
4
◄---10---►
-◄--7 ►◄ 5___...,.
The waiting time for all the processes are given as
:Waiting time for Pl= 0 ms (Pl starts executing firs.t)
Waiting time for P3 = 10 ms (P3 starts executing after completing P 1)
Waiting tiine for P2 17 ms (P2 starts executing after completing Pl and P3)
Average waiting time (Waiting time for all processes) / No. of :erocesses
= (Waiting time for (Pl +P3+P2)) / 3
= (0+10+17)/3 27/3
= 9 milliseconds
Turn Around Time (TAT) for Pl = 10 ms (Time spent in Ready Queue+ Execution Time)
iS · Turn Around Time (TAT) for P3 = 17 ms (-Do-)
IS
Tum Around Time (TAT) for P2 22 ms (-Do-)
Average Tum Around Time = (Turn Around Time for all processes) I No. of Processes
t-
= (Tum Around Time for (Pl+P3+P2)) / 3
n (10+17+22)/3 49/3
= 16.33 milliseconds

~~~~~p~~cz :)
IS Calculate the waiting. time and Tum Around Time (TAT) for each process and· the Average waiting time and Turn Around
:h Time for the above example if a new process P4 with estimated completion time 6 ms and priority 1 enters the 'Ready'
queue after 5 ms of execution of Pl. Assume all the f ')C'~;sses contain only CPU operation and no I/0 operations are
l-
involved.
a
At the beginning, there are only three processes (Pl, P2 and P3) available in the 'Ready' queue and the scheduler
0 picks lip the process with the highest priority (In this example Pl with priority 0) for scheduling. The execution sequence
e, diagram for this is same as that of Example 1. Now process P4 with estimated execution completion time 6 ms and
1e priority 1 enters the 'Ready' queue after 5 ms of execution of Pl. Since the scheduling algorithm is non-preemptive and
ts process P1. does not co?tain any I/0 operations, P1 co~tinues its_ exe~ution. A~e~ 10 n:is of sched~li~g, P)\\t~hnin~te_s and
Jf ?o"'. ~h~ scheduler agam so~s ~he. 'Read( queue for process. with highest pnonty.. S1~c_e th~ pno:1ty f~\f 4 _U?nonty 1)
1e 2!,
1s h~gher than that ~f ~3 (pnonty which w~s supp~se~ to be run after the. completion of Pl_ ·as per tht\ ~eq{l'y' que~e
m avallabl~ at the begmnmg of execution scheduling, P4 is picked up for executmg. Due to the arnval of the process P4 with
 Introduction to Embedded Systems

priority 1, the 'Ready' queue is resorted in the order Pl, P4, P3, P2. At the beginning it was Pl, P3, P2. The execution
sequence now changes as per the following diagram

0 23 28
►◄ 5--+
f
The waiting time for all the processes are given as t]
Waiting time for Pl Oms (Pl starts executing first) C
Waiting time for P4 5 ms (P4 starts executing after completing Pl. But P4 arrived after 5 ms of execution of Pl. Hence
its .waiting time = Execution start time -Arrival Time = 10 - 5 5)
I
3
Waiting time for P3 = 16 ms (P3 starts executing after completing Pl arid P4)
Waiting time for P2 = 23 ms (P2 starts executing after completing Pl, P4 and P3)
e
t
Average waiting time. (Waiting time for all processes)/ No. of Processes
s.
= (Waiting time for (Pl +P4+P3+P2)) / 4
= (0 + 5 + 16 + 23)/4 = 44/4
= 11 milliseconds
Tum Around Time (TAT) for P1 = 10 ms (Time spent in Ready Queue + Execution Time)
Tum Around Time (TAT) for P4 = 11 ms (Time spent in Ready Queue + Execution
Time = (Execution Start Time Arrival Time) + Estimated Execution
Time = (10 - 5) + 6 = 5 + 6)
Turn Around Time (TAT) for P3 = 23 ms (Time spent in Ready Queue+ Execution Time)
Tum Around Time (TAT) for P2 = 28 ms (Time spent in Ready Q~eue + Execution Time)
Average Tum Around Time = (Tum Around Time for all processes)/ No. of Processes
= (Tum Around Time {or tp2 + P4 + P3 + P1)) / 4
= (10 + 11 + 23 + 28)/4 = 72/4
18 milliseconds
Similar to SJF scheduling algorithm, non~p~eemptive priority based algorithm also possess the draw-
back of 'Starvation' where a process whose priority is.low may not get a chance to execute if more and
more processes with higher priorities enter the 'Ready' queue before the process with lower priority
started its execution. 'S[arv6fion' can be effectively tackled in priority based non-preemptive scheduling
by dynamically raising the priority of the low priority,fask/process which is under starvation (waiting
in the ready queue for a longer time for getting the CPU-time). The technique of gradually raising the
priority of processes which are waiting in the 'Readf:queue as time progresses, for preventing 'Starva-
tion', is known as 'Aging'.

10 .5. 2 Preemptive Scheduling

Preemptive scheduling is employed in systems, which implements preemptive multitasking model. In
preemptive scheduling, every task in the 'Ready' queue gets a chance to execute. When and how of-
ten each process gets a chance to execute (gets the CPU time) is dependent on the type of preemptive
scheduling algorithm used for scheduling the processes. In this kind of scheduling, the scheduler can
preempt (stop temporarily) the currently executing task/process and select another task from the 'Ready'
queue for execution. When to pre-empt a task and which task is to be picked up from the 'Ready' queue
for execution after preempting the current task is purely dependent on the scheduling algorithm. A task
which is preempted by the scheduler is moved to the 'Ready' queue. The act of moving a 'Running'
· process/task into the 'Ready' queue by the scheduler, ~ithout the ptocesses requesting fo; it is knmvn as
 Real-Time Operating System (RTOS) based Embedded System Design

on
'Preemption'. Preemptive scheduling can be implemented in different approaches. The two important
approaches adopted in preemptive scheduling are time-based preemption and priority-based preemption.
The various types of preemptive scheduling add>pted in task/process scheduling are explained ·below.
J0.S.2.1 Preemptive SJF Scheduling/Shortest Remaining Time (SRT) The non-preemptive
SJF scheduling algorithm sorts the 'Ready' queue only after completing the execution.of the current
process or when the process enters 'Wait' state, whereas the preemptive SJF scheduling algorithm sorts
the 'Ready' queue when a new process enters the 'Ready' queue and checks whether the execution time
of the new process is shorter than the remaining of the total estimated time for the currently executing
ice process. If the execution time of the new process is less, the currently executing process is preempted
and the new process is scheduled for execution. Thus preemptive SJF scheduling always compares the
execution completion time (It is same as the remaining time for the new process) of a new process en-
tered the 'Ready' queue with the remaining time for completion of the currently executing process and
schedules the process with shortest remaining time for execution. Preemptive SJF scheduling is also
known as Shortest Remaining Time (SRI) scheduling.
Now let us solve Example 2 given under the Non-preemptive SJF scheduling for preemptive SJF
scheduling. The problem statement and solution is explained in the following example.

ion

Three processes with process IDs Pl, P2, P3 with estimated completion time 10, 5, 7 milliseconds respectively enters
the ready queue together. A new process P4 with estimated completion time 2 ms enters the 'Ready' queue after-2 ms.
Assume all the processes contain only CPU operation and no 1/0 operations are involved.
At the beginning, there are only three processes (Pl, P2 and P3) available in the 'Ready' queue and the SRT.scheduler
picks up the process with the shortest remaining time for execution completion (In this example, P2 with remaining time
5 ms) for scheduling. The execution sequence diagram for this is same as that of example 1 under non-preemptive SJF
scheduling.
w-
Now process P4 with estimated execution completion time 2 ms enters the 'Ready' queue after 2 ms of start of execu-
ind tion of P2. Since the SRT algorithm is preemptive, the remaining time for completion of process P2 is checked with the
ity remaining time for completion of process P4. The remaining time for completion of P2 is 3 ms which is greater than that
tng of the remaining time for completion of the newly entered process P4 (2 ms). Hence P2 is preempted and P4 is scheduled
mg for execution. P4 continues its execution to finish since there is no new process entered in the 'Ready' queue during its
the execution. After 2 ms of scheduling P4 terminates and now the scheduler again sorts the 'Ready' queue based on 'the re-
va- maining time for completion of the processes present in the 'Ready' queue. Since the remaining time for P2 (3 ms), which
is preempted by P4 is less than that of the remaining time for other processes in the 'Ready' queue, P2 is scheduled for
execution. Due to the arrival of the process P4 with execution time 2 ms, the 'Ready' queue is re-sorted in the order P2,
P4, P2, P3, Pl. At the beginning it was P2, P3, Pl. The execution sequence now changes as per the following diagram

In
of-
ive
:;an 0 2 4 7 14 24
·dy' ...
◄ 2+-◄ 2-ti,,.◄-3-1► ◄ ..
---7--► ◄-----10 ---►
~ue
ask The waiting time for all the processes are given as
ng' Waiting time for P2 = 0 ms + (4 2) ms= 2 ms (P2 starts executing first and is interrupted by P4 and has to wait till the
las completion of P4 to get the next CPU slot)
 Introduction to Embedded Systems

Waiting time for P4 = 0 ms (P4 starts executing by preempting P2 since the execution time for completion of P4 (2 ms) is
less than that of the Remaining time for execution completion of P2 (Here it is 3 ms))
Waiting time for P3 = 7 ms (P3 starts executing after completing P4 and P2)
Waiting time for Pl = 14 ms (Pl starts executing after completing P4, P2 and P3)
Average waiting time =(Waiting time for all the processes)/ No. of Processes
= (Waiting time for (P4+P2+P3+Pl)) / 4
= (0 + 2 + 7 + 14)/4 = 23/4
'" =5.75 millisecondt
Turri Around Time (TAT) for P2 = 7 ms (Time spent in Ready Queue + Execution Time)
Tum Around Time (TAT) for P4 = 2 ms (Time spent in Ready Queue + Execution Time (Execution Start Time
-Arrival Time) + Estimated Execution Time (2 2) + 2)
Tum Around Time (TAT) for P3 = 14 ms (Time spent in Re~dy Queue + Execution Time)
Tum Around Time (TAT) for P 1 = 24 ms (Time spent in Ready Queue + Execution Time)
Average Tum Around Time (Tum Around T¥Ue for all the processes)/ No. of Processes
(Tum Around Tihle for (P2+P4+P3+Pl)) / 4
(7+2+ 14+24)/4 47/4
= 11.75 milliseconds
Now let's compare the Average Waiting time and Average Tum Around Time with that of the Average waiting time and
Average Turn Around Time for non-preemptive SJF scheduling (Refer to Example 2 given under the section Non-pre-
1
emptive SJF scheduling) '
Average Waiting Time in non-preemptive SJF scheduling =6 ms
Average Waiting Time in preemptive SJF scheduling 5.75 ms
Average Turn Around Time in non-preemptive ~JF sch~duling = 12 ms
Average Tum Around Time in preemptive S.JY fcheduling 11.75 ms
This reveals that the Average waiting Time and Turn Around Time (TAT) improves significantly with preemptive SJF
scheduling. e·
e:
10. 5.2.2 Round Robin (RR) Scheduling The term Round Robin is very popular among the sports fi
and_games activities. You plight have heard about 'Round Robin' league or 'Knock ouf league associ- p
~,d with any1football of dricket tournament. In the 'Round Robin' league each team in a group gets an tl
equal chance to play agribst the rest of the teams in the same group whereas in the 'Knock out' league
1

ii
the losing team in a match moves out of the tournament ©. fi
In the process scheduling context also, 'Round Robin' brings the same message "Equal chance to
all". In Round Robin scheduling, each process in the 'Ready' queue is executed for a pre-defined time
slot. The execution starts with picking up the first process in the 'Ready' queue (see Fig. 10.13). It is
executed for a pre-defined time and when the pre-defined time elapses or the process completes (before
the pre-defined time slice), the next process in the 'Ready' queue is selected for execution. This is i:e-
peated for all the processes in the 'Ready' queue. Once each process in the 'Ready' queue is executed for
the pre-defined time period, the scheduler comes back and picks the first process in the 'Ready' queue
again for execution. The sequence is repeated. This reveals that the Round Robin scheduling is similar
to the FCFS scheduling and the only difference is that a time slice based preemption is added to switch
the execution between the processes in the 'Ready' queue. The 'Ready' queue can be considered as a
circular queue in which the scheduler picks up the first process for execution and moves to the next till
the end of the queue and then comes back to the beginning of the queue to pick up the first process.
The time slice is provided by the timer tick feature of the time management unit of the OS kernel (Re-
fer the Time management section under the subtopic 'The Real-Time kernel' for more details on Timer
tick). Time slice is kernel dependent and it varies in the order of a few microseconds to milliseconds.
Certain OS kernels may allow the time slice as user configurable. Round Robin scheduling ensures that
 Real-Time Operating System (RTOS) based Embedded System Design

Execution Switch Execution Switch

Execution Switch

every process gets a fixed amount of€PU time for execution. When the process gets its fixed time for
execution is determined by the FCFS policy (That is, a process entering the Ready queue first gets its
fixed execution time first and so on ... ). If a process terminates before the elapse of the time slice, the
process releases the CPU voluntarily and the next process in the queue is scheduled for execution by
the scheduler. The implementation of RR scheduling is kernel dependent. The following code snippet
illustrates the RR scheduling implementation for RTX5 l Tiny OS, an 8bit OS for 8051 microcontroller
frrnm
 Introduction to Embedded Systems

RTXS 1 defines the tasks as simple C functions with void return type and void argument list. Th~ attri-
bute _task_ is used for declaring a function as task. The general form of declaring a task is ·
i{Old.;:funo {void) 'df~$"~~,tca.·,

where June is the name of the task and task_id is the ID of the task. RTXS l supports up to 16 tasks and
so task id varies from Oto 15. All tasks should be implemented as endless loops.
The two tasks in this program are counter loops .. RTXS l Tiny starts executing task O which is the
function named jobO. This function creates another task called job 1. After jobO executes for its time
slice, RTXS l Tiny switches to job 1. After job 1 executes for its time slice, RTXS l Tiny switches back to
jobO. This process is repeated forever.
Now let's check how the RTX51 Tiny RR Scheduling can be implemented in an embedded device (A
smart card reader) which addresses the following requirements.·
• Check the presence of a card
• Process the data received from the card
• Update the Display
• Check the serial port for command/data
• Process the data received from serial port
These four requirements can be considered as four tasks. Implement them as four RTXS l tasks as ex-
plained below.

{ !, •

/* .This task .
/* Implement
}

Now the tasks are created. Next step is scheduling the ta~ks. The following code snippet illustrates
the scheduling of tasks.
 Real-Time Operating System (RTOS) based Embedded System Design

l- {~s_creat~~tas~ ,(4); /* c:i:::~qte seriq);~data task T.asl<:: .* /

o·s_delete..:._t~s~ '(QJ; ·:I* DeI=ete J:he s1:a'rtup Task *T '
r·
Theos create task (task_ID) RTX51 Tiny kernel call puts the task with task ID task_ID in the
d
'Ready' state. All the ready tasks begin their execution at the next available opportunity. RTXS 1 Tiny
does not have a main Ofunction to begin the code execution; instead it starts with executing task 0. Task
le
0 is used for creating other tasks. Once all the tasks are created, task Ois stopped and removed from the
ie
task list with the os delete_task kernel call. The RR scheduler selects each task based on the time slice
:o and continues the execution. If we observe the tasks we can see that there is no point in executing the
taskprocess_card_task (Task 2) without detecting a card and executing the taskprocess_serial_data_
A task (Task 4) without receiving some data in the serial port. In summary task 2 needs to be executed only
when task I reports the presence of a card and task 4 needs to be executed only when task 3 reports the
arrival of data at serial port. So these tasks (tasks 2 and 4) need to be put in the 'Ready' state only on
satisfying these conditions. Till then these tasks can be put in the 'Wait' state so that the RR scheduler
will not pick them for scheduling and the RR scheduling is effectively utilised among the other tasks.
This can be achieved by implementing the wait and notify mechanism in the related tasks. Task 2 can
be coded in a way that it waits for the card present event and task 1 signals the event 'card detected'. In
a similar fashion Task 4 can be coded in such a way that it waits for the serial data received event and
task 3 signals the reception of serial data on receiving serial data from serial port. The following code
snippet explains the same.

i.f (card is ·present) •

:I /Signal card de.tecfed to task 2
os_send_signal (2)
}
)

void process card task (void) task 2

{
1~ This task processes the data received from the card*/
/* Implement the necessary functionality -here*/
while (1)
es {
I
· //Function for checking t4e signaling of ca
OS waitl(K_SIG); / I 1~. Jl~esent
.
event

//P~ocess card data I ( ,

y
}
 Introduction to Embedded Systems

,1
u
tl
tl
Theos send_signal (Task JD) kernel call sends a signal to task Task ID. If the specified task is already it
waiting for a signal, this function call readies the task for execution but does not start it. The os_wait] R
(event) kernel call halts the current task and waits for an event to occur. The event argument specifies the T
event to wait for and may have only the value K_SIG which waits for a signal. RTX51 uses the Timer o:
0 of 8051 for time slice generation. The time slice can be configured by the user by changing the time T
slice related parameters in the RTX5 l Tiny OS configuration file CONF_TNY.ASl file which is located e1
in the \KEIL\CSl \RTXTINY2\ folder. Configuration options in CONF_TNY.ASl allow users to:
• Specify the Timer Tick Interrupt Register Bank.
• Specify the Timer Tick Interval (in 8051 machine cycles).
• Specify user code to execute in the Timer Tick Interrupt.
• Specify the Round-Robin Timeout.
• Enable or disable Round-Robin Task Switching. C
• Specify that your application includes long duration interrupts. Tl
• Specify whether or not code banking is used. re
• Define the top of the RTX51 Tiny stack. ar
• Specify the minimum stack space required. ril
• Specify code to execute in the event of a stack error.
• Define idle task operations.
The RTX51 kernel provides a set of task management functions for managing the tasks. At any point
of time each RTX51 task is exactly in any one of the following state.
 Real-Time Operating System (RTOS) based Embedded System Design

Refer the documentation available with RTX51 Tiny OS for more information on the various RTX5 l
task management kernel functions and their usage.
RR scheduling with interrupts is a good choice for the design of comparatively less complex Real-
.Time Embedded Systems. In this approach, the tasks which require less Real-Time attention can be sched-
uled with Round Robin scheduling and the tasks which require Real-Time attention can be scheduled
through Interrupt Service Routines. RTX51 Tiny supports Interrupts with RR scheduling. For RTX5l
the time slice for RR scheduling is provided by the Timer interrupt and if the interrupt is of high prior-
ity than that of the timer interrupt and if its service time (ISR) is longer than the timer tick interval, the
RTX5 l timer interrupt may be interrupted by the ISR and it may be reentered by a subsequent RX5 l
Tiny timer interrupt. Hence proper care must be taken to limit the ISR time within the timer tick interval
or to protect the timer tick interrupt code from reentrancy. Otherwise unexpected results may occur.
The limitations.of RR with interrupt generic approach are the limited number of interrupts supported by
embedded processors and the interrupt latency happening due to the context switching overhead.
RR can also be used as technique for resolving the priority in scheduling among the tasks with same
level of priority. We will discuss about how RR scheduling can be used for resolving the priority among
equal tasks under the VxWorks kernel in a later chapter,

Three processes with process IDs Pl, P2, P3 with estimated completion time 6, 4, 2 milliseconds respectively, enters the
ready queue together in the order P 1, P2, P3. Calculate the waiting time and Tum Around Time (TAT) for each process
and the Average waiting time and Tum Around Time (Assuming there is no I/O waiting for the processes) in RR algo-
rithm with Time slice 2 ms.
. J

. The scheduler sorts the 'Reqdy' queue based on the FCFS policy and picks up the first process Pl from the 'Ready'
queue and executes it for .the time slice 2 ms. When the time slice is expired, Pl is preempted and P2 is scheduled for
ex~cution. The Time s\ice expires after 2ms of execution of P2. Nof P2 is preempted and P3 is picked up for execution.
P3 completes its execution within the time slice and the scheduler :ricks P 1 again for execution for the next time slice.
This procedure is repeat~d till all the processes are serviced. The order in which the processes are scheduled for execution
is represented as '
 Introduction to Embedded Systems

((
C(
i
0 2 4 6 8 12 C(

,._2 11 ◄ 2 ►◄ 2 ►◄ 2 ►◄ 2 ►◄ 2_..,.
Ui
The waiting time for all the processes are given as
WaitingtimeforPl = 0+(6-2)+(10-8) 0+4+2=6ms S1
'(Pl starts pxecuting first and waits for two time slices to get execution back and again 1 time A
slice for g~tting CPUtime) p
Waiting time for P2 = (2 0) + (8 - 4) 2 + 4 6 ms
(1
(P2 starts executing after Pl executes for I time slice and waits for two time slices to get the CPU
time)
C
Waiting time for P3 = (4 0) = 4 ms 1
.
1
(P3 starts executing after completing the first time slices for P 1 and P2 and completes its execu-
tion in a single time slice)
Average waiting time (Waiting time for all the processes)/ No. of Processes
= (Waiting time fo.r (Pl + P2 + P3))/ 3 ·
= (6 + 6 + 4)/3 = 16/3
5.33 milliseconds 1
Tum Around Time (TAT) for P 1 = 12 ms (Time spent in Ready Queue+ Execution Time)
Turn Around Time (TAT) for P2 = 10 ms (-Do-)
Tum Around Time (TAT) for P3 = 6 ms (-Do-)
Average Turn Around Time = (Tum Around Time for all the processes) / No. of Processes
= (Tum Around Time for (Pl+ P2 + P3))/3
(12 + 10 + 6)/3 = 28/3
= 9.33 milliseconds
Average Tum Around Time (TAT) is the sum of average waiting time and average execution time.
Average Execution time = (Execution time for all the process)/No. of processes
= (Execution time for (Pl + P2 + P3))/3
(6 + 4 + 2)/3 12/3
=4
Average Tum Around Time Average Waiting time+ Average Execution time
= 5.33 + 4
= 9.33 milliseconds
RR scheduling involves lot of overhead in maintaining the time slice information for every process
which is currently being executed. ·
10.5.2.3 Priority Based Scheduling Priority based preemptive scheduling algorithm is same as
that of the non-,preemptive priority based scheduling except for the switching of execution between
tasks. In preemptive scheduling, any high priority process enteri11g the 'Ready' queue is immediately·
scheduled for execution whereas in the non-preemptive scheduling any high priority process entering
the 'Ready' queue is scheduled only after the currently executing process completes its execution or
only when it voluntarily relinquishes the CPU. The priority of\ task/pro<;tess in preemptive scheduling
is indicated in the same way as that of the mechanism adopted for non-preemptive multitasking. Refer
the non-preemptive priority based scheduling discu,,ss~ct',,in an earlier skction of this chapter for more
details. ·
 Real-Time Operating System (RTOS) based Embedded System Design

Three processes with process IDs Pl, P2, P3 with estimated completion time 10, 5, 7 milliseconds and priorities 1, 3, 2
(O-highest priority, 3-lowest priority) respectively enters the ready queue together. A new process P4 with estimated
completion time 6 ms and priority Oenters the 'Ready' queue after 5 ms of start of execution of P 1. Assume all the pro-
cesses contain only CPU operation and no I/0 operations are involved.
At the beginning, there ~re only three processes (Pl, P2 and P3) available in the 'Ready' queue and the scheduler picks
up the process with the highest priority (ln this example Pl. with priority 1) for scheduling.
Now process P4 with estimated execution completion time 6 ms and priority Oenters the 'Ready' queue after 5 ms of
start of execution of Pl. Since the scheduling algorithm is preemptive, Pl is preempted by P4 and P4 runs to completion.
After 6 ms of scheduling, P4 terminates and now the scheduler again sorts the 'Ready' queue for process with highest
priority. Since the ptiority for Pl (priority 1), which is preempted by P4 is higher than that of P3 (priority 2) and P2
((priority3), Pl is again picked up for execution by the scheduler. Due to the arrival of the process P4 with priority 0, the
'Ready' queue is resorted iq the order Pl, P4, Pl, P3, P2.At the beginning it was Pl, P3,P2. The execution sequence now
changes as per the following diagram

0 5 11 16 23 28
<!lf--5 ►◄ 6 ►◄ 5 ►◄ 7 ►◄ 5--►-

The waiting time for all the processes are given as

Waiting time for Pl . 0 + (11 5) 0 + 6 = 6 ms
(P 1 starts-executing first and gets preempted by P4 after 5 ms and again gets the CPU time after
completion of P4)
Waiting time for P4 0 ms
(P4 starts executing immediately o~ entering the 'Ready' queue, by preempting Pl)
Waiting time for P3 16 ms (P3 starts executing after completing Pl and P4)
Waiting time for P2 23 ms (P2 starts executing after completing Pl, P4 and P3)
Average waiting time (Waiting time for all the processes) i No.' of Processes
.'(Waiting time for (Pl+P4+P3+P2)) / 4
(6 + 0 + 16 + 23)/4 = 45/4
11.25 milliseconds
Turn Around Time (TAT) for Pl= 16 ms (Time spent in Ready Queue+ Execution Time)
Turn Around Time (TAT) for P4 6 ms
(Time spent in Ready Queue+ Execution Time (Execution Start Time Arrival Time)+ Esti-
mated Execution Time= (5 - 5) + 6 = 0 + 6)
Turn Around Time (TAT) for P3 = 23 ms (Time spent in Ready Queue + Execution Time)
Turn Around Time (TAT) for P2 28 ms (Time spent in Ready Queue + Execution Time)
Average Turn Around Time (Turn Around Time for all the processes)/ No. of Processes
(Tum Around Time for (P2 + P4 + P3 + P1)) I 4
= (16 + 6 + 23 + 48)/4 = 73/4
18.25 milliseconds
 Introduction to Embedded Systems

Priority based preemptive scheduling gives Real-Time attention to high priority tasks. Thus priority
based preemptive scheduling is adopted in systems which demands 'Real-Time' behaviour. Most of
the RTOSs make use of the preemptive priority based scheduling algorithm for process scheduling.
Preemptive priority based scheduling also possesses the same drawback of non-preemptive priority
based scheduling-' Starvation'. This can be eliminated by the 'Aging' technique. Refer the section Non-
preemptive priority based scheduling for more details on 'Stanmtion' and 'Aging'.

So far we discussed about threads, processes and process/thread scheduling. Now let us have a look at
how these entities are addressed in a real world implementation. Let's examine the following pieces of
code.
I/**** :I'********_*-********-*********************,**·****** *t*.**·* ** * * * *,* **
//Process
; ' \··. ''.' '•'·"
1 .. -~~~_;:_ :::-, ,• .'. ,,· <:.,.,:., ,- -.:.>;;_,:,. 't +-,_, ;• ' ~--:;_,,, • '-,-' .:- - '·-,~· • ··,. ,, •' .

:~~;1~:: ::t~fd1tl~},<r/>.; :·:w•,: ~- ;:'

I I********** ***:'k~ ***~*~'1<*** -* * **.**:**'** *:* */ *·** **} *>*.:-1\•~'** ****** ** *** ** **

I I********:********* ***::*\"15**** ***.**'~\,J:it,f* * *.t t** ** *

. . - :s - - ;' .. .,

** * *;'; * ** ** * * * *
· 1 /ThrJact fb,r. eX:Jb1.1t.in•g.i~afask: .·· . .
I/;*~******* *,**i::t **·**.f;.:'t./'i:t **- * *·* * * * *·* * * * *,* * *t.~t.* *.*.t ** * * *:**. * * *.* *:?' * * * * * *
vqid, T.ask (void)· .{

.·w.hile ( 1)
'{ .
//Perform some task
//T~~k execution time is~-~ finits of executipn
//Sleep·ioF 17.5 ~nit~ of-execuiion-
Sleep(l7.S); //Parameter giv~n.i:5 r;iqt i,n\1Ui1Jisecofrds
//Repeat task
}
}
//******~******************;*********~**********i*******************
//Main Thread.
//********************************************************~*********
void main(void) {
DWORD id;
HANDLE hThread;
//Create thread with normal priority
//******************************************************************
hThread = CreateThread(NULL,0,
(~PTHREAD_START_ROUTINE)Task,
(LPVOID) 0, 0, &id);
if (NULL==hThread)
{//Thread Creation failed. Exit process
printf("Creating thread failed: Error Code
%d",GetLastError());
 Real-Time Operating System (RTOS) based Embedded System Design

return;

WaitFOrSingleObject (hThread, INF.INITE);

y ·return;.
1-
'.-}
) /*.* * * * ** ** * * **'*** ** * * * * * * * * ** **t *·** **"*.* ***.* ** * *
'/hr'o~ess 2 ·
~i§f-1c":/i* *****~-!<ii *~ .; ** * *_';,\ **~-* * *~;;; .;.-..:;:*t** {* *'*

:1.t
>f
; i; w~!~~i~ifi~~;;,~,iji~~t:f:i:••~~
f/,!/Tb.~ead
1 fo<r ·executi:-ng, -:r'q.sk ..._,, . ··. ,. ,, .· , •·, ,. . .
Jl'*""l*if** * *, *;t. .u *:** * ~'*.* *.i *;,1;,1,;/J.. t.t*tt1.t•tt~ti~:Hr/:**
15
*•• * .;¥,.,. h •

, void c'Task(v9id) , { / .
?;:~}ii:t;~•..·£ 1). ,/:< :· .i:, ":;'\
:,;- -><~<
/V ~h,,:.I1·, ,

://PeFf:or.m soi:ne ''task ,

j/(1:2.fip~e~~~isn tim,~ ~s. 10_._~?t-t,~ ·?.t.?:~':o.ut~on '. _'.
:J/~leep fg:i;-· :)_ u9it's · ofexec:qtion
t§.te'ep:f sf; JI Pala'metei .g'iv~·n:t;r;' -n~i· 1~~'~1-iiis~~~n·~~ -
('5J:y_~~p~kt ;tai1t' -·\ - ,·•>? ·· ( . ,..; :"· >\,; -
,-- ·.- ,.-t ~-~-'- ~ ,< "
,<•-'~7-;,'t• •

1~~********~~****~~~ ** *'*.i **** ** * ***~ *1:.-***'*** ** ***'**'/,;* ****** ** *-ir'I<*

,.},~/.,'

/Ma''in Th read.
:;,;,/ **. *,* ***- ** * *'f'.'f;/! *.,,* * * * * 1< * * * ** -1( *.******-If***!',,*****
' ,' ' . . 'If****** -1:f* **,* * 7c *. * ** t***
,, ,. ~

· iroid .main (voitj) . {..

, DWORD id;
HANDLE .,hThread;
1//Create t;l1r~ad with .aboye nor1;1al priority .•. . . . .
~7/***~*;*;**~*t~;*~**~****ii**~~*;**************~*;~*********~~*****
hThread = CreateThread(NULL,0,
(LPTHREAD_START_ROUTINE)Task,
(LPVOID) 0, CREATE_SUSPENDED, &id);
if (NULL=~hThread)
{//Thread Creation failed. Exit process
princf("Creating thread failed: Error Code
%du,GetLastError());
return;

SetThreadPriority(hThread,THREAD PRIORITY ABOVE_NORM..~L);

ResumeThread(hThread);
WaitForSingleObject(hThread, INFINITE);
return;

The first piece of code represents a process (Process 1) with priority nonnal and it perfonns a task
which requires 7. 5 units of execution time. After perfom1ing this task, the process sleeps for 17.5 units
of execution time and this is repeated forever. The second piece of code represents a process (Process
 Introduction to Embedded Systems

2) with priority above normal and it performs a task which requires 10 units of execution time. After
performing this task, the process sleeps for 5 units of execution time and this is repeated forever. Process
2 is of higher priority compared to process 1, since its priority is above 'Normal'.
Now let us examine what happens if these processes are executed on a Real-Time kernel with pre-
emptive priority based scheduling policy. Imagine Process 1 and Process 2 are ready for execution. Both
of them enters the 'Ready' queue and the scheduler picks up Process 2 for execution since it is of higher
priority (Assuming there is no other process running/ready for execution, when both the processes are
'Ready' for execution) compared to Process 1. Process 2 starts executing and runs until it executes the
Sleep instruction (i.e. after 10 units of execution time). When the Sleep instruction is executed, Process 2
enters the wait state. Since Process 1 is waiting for its turn in the 'Ready' queue, the scheduler picks up
it for execution, resulting in a context switch. The Process Control Block (PCB) of Process 2 is updated
with the values of the Program Counter (PC), stack pointer, etc. at the time of context switch. The esti-
mated task execution time for Process 1 is 7.5 units of execution time and the sleeping time for Process
2 is 5 units of execution. After 5 units of execution time, Process 2 enters the 'Ready' state and moves
to the 'Ready' queue. Since it is of higher priority compared to the running process, the running process
(Process 1) is pre-empted and Process 2 is scheduled for execution. Process 1 is moved to the 'Ready'
queue, resulting in context switching. The Process Control Block of Process 1 is updated with the cur-
rent values of the Program Counter (PC), Stack pointer, etc. when the context switch is happened. The
Program Counter (PC), Stack pointer, etc. for Process 2 is loaded with the values stored in the Process
Control Block (PCB) of Process 2 and Process 2 continues its execution form where it was stopped ear-
lier. Process 2 executes the Sleep instruction after 10 units of execution time and enters the wait state.
At this point Process 1 is waiting in the 'Ready' queue and it requires 2.5 units of execution time for
completing the task associated with it (The total t1me for completing the task is 7.5 units of time, out
of this it has already completed 5 units of execution when Process 2 was in the wait state). The sched-
uler schedules Process 1 for execution. The Program Counter (PC), Stack pointer, etc. for Process 1 is
loaded with the values stored in the Process Control Block (PCB) of Process 1 and Process 1 continues
its execution form where it was stopped earlier. After 2.5 units of execution time, Process 1 executes the
Sleep instruction and enters the wait state. Process 2 is already in the wait state and the scheduler finds
no other process for scheduling. In order to keep the CPU always busy, the scheduler runs a dummy
process (task) called 'IDLE PROCESS (TASK)'. The 'IDLE PROCESS (TASK)' executes some dummy
task and keeps the CPU engaged. The execJtion diagram depicted in Fig. 10.24 explains the s'equence
of operations.
The implementation of the 'IDLE PROCESS (TASK)' .is dependent on the kernel and a typical imple-
mentation for a desktop OS may look like. It is simply an endless loop.
/

void.Idle' Process (void)

//Simply wait.
I /Do notl:,ling .. '.
While (1);.
}

The Real-Time kernels deployed in embedded systems, where operating power is a big constraint
(like systems which are battery powered); the 'IDLE TASK' is used for putting the CPU into IDLE mode
for saving the power. A typical example is the RTX51 TJ_gy Real-Time kernel, where the 'IDLE TASK'
sets the 8051 CPU to IDLE mode, a power saving mode: In the 'IDLE.' mode, the program execution is
 Real-Time Operating System (RTOS) based Embedded System Design

Waiting

Running

!'SR;;\ Ready

IDLE TASK

Process 2
(High Priority)
Process 1
(Low Priority)

halted and all petjpherals and the interrupt system continues its operation. Once the CPU is put into the
'IDLE' mode, it ¢omes out of this mode when an Interrupt occurs or when the RTX5 l Tiny Timer Tick
Interrupt (The timer interrupt used for task scheduling in Round robin scheduling) ·occurs. It should be
noted that the 'IDLE PROCESS (TASK)' execution is not pre-emptive priority scheduling specific, it is
applicable to all' types of scheduling policies which demand 100% CPU utilisation/CPU power saving.
Back to the desktop OS environment, let's analyse the process, threads and scheduling in the Win-
dows desktop environment. Windows provide a utility called task manager for monitoring the different
process running on the system and the resources usetl by each process. A snapshot of the process details
returned by the task manager for Windows XP kernel is shown in Fig. 10.15. It should be noted that
this snapshot is purely machine dependent and it varies with the number of processes running on the
machine.
'Image Name' represents the name of the process. 'PID' represents the Process Identification Number
(Process ID). As mentioned in the 'Threads and Process' section, when a process is created an ID is
associated to it. CPU usage. gives the% of CPU utilised by the process during an interval. 'CPU Time'
gives the total CPU time used by a process after its corni:nencemerit. 'Mem Usage' represents the total
main memory; in, kilobytes, used by the process. 'VM Size' represents the total virtual memory (paged
memory), in kilobytes, used by a process. 'Paged Pool' represents the paged memory, in kilobytes, cur-
rently used by the system. 'NP Pool' is the non-paged pool or system memory used by a process. The
non-paged memory is not swapped to the secondary st-0rage disk. 'Base Pri' rp?resents the priority of
 Introduction to Embedded Systems

C
sl
di

4 0:07:53 212K OK C
164 0:00:33 6,500K 1,732K 35K 3K Normal 69
200 0:00:09 4,012K 2,556K 36 K 3K Normal 89 3 .re
284 0:00:00 1,648 K 444 K 18K !K Normal 37 2
Normal
292
312
00
00
0:00:51
0:00:05
22,076K
3,404 K
18,564K
2,668K
32K
23K
4K
2K Normal
143
17
7
I
C
420
468
00
00
0:00:04
0:02:ll
2,748K
4,028K
1,236K
1,668 K
17K
75K
3K
7K
Normal
High
73
897
3
13
n
500 00 0:00:0l 1,528K Hok 14K lK Normal 33 4
508 00 0:00:10 6,748K 4,432 K 45K SK Normal 161 10
532 00 0:00:16 3,826K 10,468K 84K 68K High 750 36
618 00 0:07:46 53,348K 126K 22K Normal 3,464 18
C1
54,852 K
656
668
00
00
0:02:17
0:00:15
6,648K
1,596 K
5,408K
4,960K
262K
56K
IOK
11 K
Normal
Normal
400
599
16
21
T
676
732
05
00
0:00:30
0:00:02
7,372K
4,280K
2,196K
2,020 K
43 K
38K
4K
llK
High
Normal
114
104
3
8
(1
740
752
00
00
0:00:05
0:00:04
24,444 K
3,784K
39,976K
2,248K
76K
32K
37K
2K
Normal
Normal
1,381
116
l3
3
e
924 00 0:00:02 5,048 K 1,996 K 44K 3K Normal 150 5
1024 00 0:12:28 16,104 K 18,392 K 98K !BK Normal 616 14
1100 00 0:01:16 4,80'! K l°3,640K 69K 8K Normal 253 9
1104 00 0:00:03 880K 12,144 K 41 K 7K Normal 139 8
]
1120 00 0:00:17 16,456 K 19,736 K 98K l7 K Normal 559 15
1204 00 0:00:01 4,036 K 2,652K 40K 3K Normal 86 4
1316 02 0:05:39 I0,212 K 6,000 K 56K 34K Normal 492 27 F
1376 00 0:03:45 2,768 K 704K 24 K 2K Normal 130 3
1384 00 0:00:43 5,924K 2,792K 56K 13K Normal 564 10 t1
1432 00 0:00:22 22,088K 29,7'18K 44K 9K Normal 294 29
l488 00 0:00:00 1,'196 K 664 K 9K 2K Normal 23 2
t,
1512 00 0:01:23 23,468K 19,804 K 26K 4K Normal 146 20
154'1 00 0:00:02 2,'128K 672K 22K 2K Normal 87 2 t
1556 00 0:06:22 2,848 K 17,296K 58K 19K Normal 363 21
1572 00 0:00:01 136K 648 K 17 K 1K Normal 42 2 r
1608 00 0:07:05 26,992K 21,636 K 50K 7K Normal 224 11
1624 00 0:00:26 10,632K 5,668K 36K. 37K Normal 196 l4 t·
1720 00 2:07:29 7,452K 33,352K 61 K 8K Normal 320 25
1836 00 0:32:43 5'1,812 K 45,372K 278K 306 K Normal 2,207 63 t
1848 00 0:02:09 4,332 K 1,784 K 37K 5K Normal 112 6
1892 00 0:00:14 2,220K 2,164K 30 K 2K Normal 56 2 I
1900 00 0:00:04 4,048K 1,612 K 38K 3K Normal 95 3
1912 00 0:00:00 372K 168K SK OK Normal 18 3
i (
2084 00 0:00:0l 672K 23K 2K 93
2124 00 0:00:13 1,964 K 30K 2K

( Fig. 10. 15) Windows XP task manager for monitoring process and resource usage

the process. As mentioned in an earlier section, a process may contain multiple threads. The 'Threads'
section gives the number of threads present in a process. 'Handles' reflects the number of object handles
owned by the process. This value is the reflection of the object handles present in th~ process's object
table. 'User Objects' reflects the number of objects active in the user mode for a process. Use 'Ctrl'
+ 'Alt' + 'Del' key for accessing the task manager and select the 'View' ➔ 'Select Columns' option to
select the different monitoring parameters for a process.

In a multitasking system, multiple tasks/processes run concurrently (in pseudo parallelism) and each
process may or may not interact between. Based on the degree of interaction, the processes running on
an OS are classified as
Co-operating Processes: In the co-operating interaction model one process requires the inputs from
other processes to complete its execution.
 Real-Time Operating System (RTOS) based Embedded System Design

Competing Processes: The competing processes do not share anything among themselves but they
share the system resources. The competing processes compete for the system resources such as file,
display device, etc.
Co-operating processes exchanges information and communicate through the following methods.
Co-operation through Sharing: The co-operating process exchange data through some shared
resources.
Co-operation through Communication: No data is shared between the processes. But they commu-
nicate for synclironisation.
The mechanism through which processes/tasks communicate each other is known as Inter Pro-
cess/Task Comn;mnication (IPC). Inter Process Communication is essential for process co-ordination.
The various types of Inter Process Communication (IPC) mechanisms adopted by process are kernel
(Operating System) dependent. Some of the important IPC mechanisms adopted by various kernels are
explained below.

10. 7.1 Shared Memory

Processes share some area of the memory to com-
municate among them (Fig. 10.16). Information
to be communicated by the process is written to
~~~~~=r~s~:~:at%:a·c~~~~drt~~e~:~ew~;~ (Fig."JR:!~) :9§-~b~~f~~f:~h~€;~,,~~i}~i-t ·
the shared memory area. It is same as the real world example where 'Notice Board' is used by corporate
to publish the public information among the employees (The only exception is; only corporate have the
right to modify the-information published on the Notice board and employees are given 'Read' only ac-
cess, meaning it is only a one way channel).
The implementation of shared memory concept is kernel dependent. Different mechanisms are ad-
opted by different kernels for implementing this. A few among them are:
10. 7.1.1 Pipes 'Pipe' is a section of the shared memory used by processes for communicating. Pipes
follow the client-servert architecture. A process wl;lich creates a pipe is known as a pipe server and a
process which connects to a pipe is known as pipe client. A pipe can be considered as a conduit for
infonnation flow and has two conceptual ends. It can be unidirectional, allowing information flow in
one direction or bidirectional allowing bi-directional information flow ..A unidirectional pipe allows the
process connecting at one end of the pipe to write to the pipe and the process connected at the other end
of the pipe to read the data, whereas a bi-directional pipe allows both reading and writing at one end.
The unidirectional pipe can be visualised as
Process l Process 2
Write Read

(Fig. 10.17) Concept,of Pipe for IPC

!
tClient Server is a software architecture. containing a client application and a server application. The application which sends request is
known as client and the application which receives the request process it and sends a response back to the client is known as server. A
server is canahle of receiving reauest from multink._cLie.nt&. • ,.
 Introduction to Embedded Systems

The implementation of 'Pipes' is also OS dependent. Microsoft® Windows Desktop Operating

Systems support two types of 'Pipes' for Inter Process Communication. They are:
Anonymous Pipes: The anonymous pipes· are unnamed, unidirectional pipes used for data transfer
between two processes.
Named Pipes: Named pipe is a named, unidirectional or bi-directional pipe for data exchange between
processes. Like anonymous pipes, the process which creates the named pipe is known as pipe server. A
process which connects to the named pipe is known as pipe client. With named pipes, any process can
act as both client and server allowing point_-to-point c_ommunication. Named pipes can be used for com-
municating between processes running ori the same.machine or between processes running on different
machines connected to a network.
Please refer to the Online Learning Cen~e for details on the Pipe implementation under Windows
Operating Systems.
Under Vx Works kernel, pipe is a special impl_ementation of message queues. We will discuss the
same in a latter chapter.
10. 7.1.2 Memory Mapped Objects Memory mapped object is a shared memory technique ad-
opted by certain Real-Time Operating Systems for allocating a shared block of memory which can be
accessed by multiple process simultaneously (of course certain synchronisation techniques should be
applied to prevent inconsistent results). In this approach a mapping object is created and physical stor-
age for it is reserved and committed. A process can map the entire committed physical area or a block
of it to its virtual address space. All read and write operation to this virtual address space by a process is
directed to its committed physical area. Any process which wants to share data with other processes can
map the physical memory area of the mapped object to its virtual memory space and use it for sharing
the data.
Windows CE 5.0 RTOS uses the memory mapped-otject based shared memory technique for Inter
Process Communication (Fig. 10.18). The CreateFileMapping {HANDLE hFile, LPSECURITY_ATTRI-
BUTES lpFileMappingAttributes, DWORD flProtect, DWORD dwMaximumSizeHigh, DWORD dw-
MaximumSizeLow, LPCTSTR lpName) system call is used for sharing the memory. This API call is used
for creating a mapping from a file. In order to create the mapping from the system paging memory, the
handle parameter should be passed as INVALID _HANDLE_VALUE (-1). The lpFileMappingAttributes
parameter represents the securify attributes and it must be NULL. The flProtect parameter represents the
read write access for the shared memory area. A value of PA GE_R.EADONLY makes the shared memory
read only whereas the value PAGE_READWRITE gives read-write access to the shared memory. The
parameter dwMaximumSizeHigh specifies the higher order 32 bits of the maximum size of the memory
mapped object and dwMaximumSizeLow specifies the lower order 32 bits of the maximum size of the
memory mapped object. The parameter lpName points to a null terminated string specifying the name of
the memory mapped object. The memory mapped object is created as unnamed object if the parameter
lpName is NULL. If lpName specifies the name of an existing memory mapped object, the function re-
turns the handle of the existing memory mapped object to the caller process. The memory mapped object
can be shared between the processes by ei~her passing the handle of the object or by passing its n:ame.
If the handle of the memory mapped object created by a process is passed to another process for shared
access, there is a possibility of closing the handle by the process which created the handle while.it is in
use by another process. This will throw OS level exceptions. If the name of the memory object is passed
for shared access among processes, processes can use this name for creating a shared memory object
which will open the shared memory object . !
already existing with the given name. The OS will maintain a
 Real-Time Operating System (RTOS) based Embedded System Design

Process 1 Process 2
..................
hPIFileMap= hP2FileMap =
CreateFileMapping CreateFileMapping
(HANDLE) -1, (IL>\NDLE) -l,
NULL, NULL,
PAGE_READWRITE, PAGE_READWRITE,
0, 0x8000, 0, 0x8000,
''memorymapobjeet"); "mernorymapobject");

......
"hP!MapView = Map View O!File hP2MapView = Map View O!File
(hPIFileMap, (hP IFileMap,
F!LE_MAP_WRITE, FILE_MAP_WRITE,
0,0,0); 0,0,0);

Process l's Virtual Memory Process 2's Virtual Memory

space space

0X6000 8000 0X6000 8000

(Arbitrary location) (Arbitrary loeation)
The memory mapped object is The memory mapped object is
mapped into Process l 1s virtual mapped into Process 2's virtual
0X6000 0000
address space address space
' ! - - - - - - - (Arbitrary location)
I 0X6000 0000
(Arbitr"'! location)

usage count for the named object and it is incremented each time when a process creates/opens a memory
mapped object with existing name, This will prevent the destruction of a shared memory object by one
process while it is being accessed by another proc~ss. Hence passing the name of the memory mapped
object is strongly recommended for memory mapped object based inter process communication. The
MapViewOJFile (HANDLE hFileMappingObject DWORD dwDesiredAccess, DWORD dwFileOffs-
etHigh, DWORD dwFileOffsetLow, DWORD dwNumberOJBytesToMap) system call maps ayiew of the
memory mapped object to the address space of the calling process. The parameter hFileMappingObject
specifies the handle to an existing memory mapped object. The dwDesiredAccess parameter represents
the read write access for the mapped view area. A value of FILE_MAP_ WRITE makes the view access
read-write, provided the memory mapped object hFileMappingObject is created with read-write ac-
cess, whereas the value FILE_MAP_READ gives read only access to the shared memory, provided the
memory mapped object hFileMappingObject is created with read-write/read only access. The parameter
dwFileOffsetHigh specifies the higher order 32 bits and dwFileOffsetLow specifies the lower order 32
bits of the memory offset where mapping is to begin from the memory mapped object. A value of 'O'
for both of these maps the view from the beginning memory area of the memory object. dwNumberOf
BytesToMap specifies the number of bytes of the memory object to map. If dwNumberOjBytesToMap
is zero, the entire memory area owned by the memory mapped object is mapped, On successful execu-
tion, Map ViewOjFile call returns the starting address of the mapped view. If the function fails it returns
NULL. A mapped view of the memory mapped object is unmapped by the API call Unmap ViewOJFile
(LPCVOJD lpBaseAddress). The lpBaseAddress parameter specifies a pointer to the base address of
the mapped view of a memory object that is to be unmapped. This value must be identical to the value
returned by a previous call to the Map ViewOjF'ile function, Calling Unmap ViewOJFile cleans up the
committed physical storage in a process's virtual address space. In other words, it frees the virtual ad-
dress space of the mapping object. Under Windows NT/XP OS, a process can open an existing memory
mapped object by calling the API OpenFileMapping(D WORD dwDesiredAccess, BOOL blnheritHan-
dle, LPCTSTR lpName). The parameter dwDesiredAccess specifies the read write access permissions fot
 Introduction to Embedded Systems

the memory mapped object. A value of FILE_MAP__ALL_ACCESS provides read-write access, whereas
the value FILE MAP_READ allocates only read access and FILE_MAP_ WRITE allocates write only
access. The parameter blnheritHandle specifies the handle inheritance. If this parameter is TRUE, the
calling process inherits the handle of the existing object, otherwise not. The parameter lpName specifies
the name of the existing memory mapped object which needs to be opened. Windows CE 5.0 does not
support handle inheritance and hence the API call OpenFileMapping is not supported.
The following sample code illustrates the creation and accessing of memory mapped objects across
multiple processes. The first piece of code illustrates the· creation of a memory mapped object with name
"memorymappedobject" and prints the address of the memory location where the memory is mapped
within the virtual address space of Process 1.
#include ~stdio.h>
#include <windows .·h>
/./ * ** ** *** * * * * * * ** *,* * .t* * *~* * ~ ** * *** * ~**·*
//Process 1: Creates the men:<:lrymapped
//Pr0c:::ess l's Virtual. Addres$ space

void main () {
//Define.the ha:ndle.to,Memory,mappedObject
HANDLE hFil.eMap;
/ /Define the handle to. th'e <~~mory 1 miipped Object·
~- .LPTSTR hM~p\Jl~,y; ' < . ; :' -.: ,, '/. . ',
· ... ··tf.. (;'/·'1;
1pn.n· · /*************·:,h:**'*t,.:;fi:.ic.,:._:;/{:,,******;**
· · ·_. · .. · -·•· .·· .. · ·, · **.•. ***.*· *. ·-.\._n· ".)_·,·.·
printf (" · Prsicess .1\nf') ,_
1
prin tf ("/ / ** *** ** ** * * ****** ****'**** ·"h-* * ** * * * *** ** **-;**\n 11 ) /· I
//Create an 8 KB memoty ma:pped 6bject ]
hFileMap = CreateFi l~Mappin~ ( ,. (HANDLE) -1,
NULL, JI de:faul t seluri"tY a:ttributes
PAGE_READWRITE, // Read-Write Access
0, //Higher order 32 bits of the memory mappintj object
Ox2000, //Lower 32 bits of the memory mapping object
TEXT("memorymappedobject")); // Memory mapped object name
if (NULL== hFileMap)

printf ("Memory mapped Object Creation Failed: Error Code: %d\n", GetLastError
() ) ;
//Memory mapped Object Creation failed. Return
return;

//Map the memory mapped object to Process l's address space

hMapView= (LPTSTR) MapViewOfFile(hFileMap,
FILE MAP WRITE,
0, //Map the entire view
0,
0) ;
if (NULL hMapView)
 Real-Time Operating System (RTOS) based Embedded System Design

printf ("Mapping of Me~ory mapped view Failed: E;rr:~r Code:

%d\n", Get.LastError ());
//Memory mapped view Creation failed. Return
return;

else

/ /Wait for usE='i _ipput to. exit. Ruµ Erpcess 2 before providigg
//user input,·
printf ("~r.~s~C{any.t~iAio t\c;fffilnate Process'_ 1'');
getchar();
/ /Unmap the _ yi~w .. .,
r.i11mapVi~wol:Fil'.t:{~f:1c1~yiew i'-;
//Giose m~mory .rtiappeci object h_a9d.le,
C_loseHandle(hFileMap); ;/ '
return;
, }

The piece of code given below corresponds to Process 2. It illustrates the accessing of an existing
memory mapped object (memory mapped object with name "memorymappedobjecC-created by Process
1) and prints the address of the memory location where the memory is mapped within the virtual address
space of Process 2. To demonstrate the application, the program corresponding to Process 1 should be
executed first and the program corresponding to Process 2 should be executed following Process 1.
#include <stdio.h>
#include <windows.h>
//**********************************************~*********~**********
//Process 2: Opens the memory mapped object created by Process 1
//Maps the object to Process 2's virtual address space.
//*******************************************************************
void main () {
/7befine the handle for the M~mory mapped Object
HANDLE hChildFileMap;
//Define the handle for the view of Memory mapped Object
LPTSTR hChildMapView;
printf("//**********************************************\nn);
printf(" Process 2\n");
printf("//**********************************************\n");
//Create an 8 KB memory mapped object
hChildFileMap Creat$'FileMapping
:\
( INVALID- HANDLE- VALUE,
NULL, // deiault security attributes
PAGE READWRITE, // Read-Write Access
0, //Higher order 32 bits of the memory mapping object
 Introduction to Embedded Systems

0x2000, //Lower order 32 bits of the memory mapping object

TEXT ("memorymappedobj ect") ) ; / / Memory mapped object name 2
if (NULL== hChildFileMap I I INVALID_HANDLE_VALUE == hChildFileMap)

printf ("Memory mapped Object Creation Failed: Error Code: %d\n",

GetLastError ());
//Memory mapped Object Creation failed. Return
return;

else

if (ERROR_ALREADYc..:EX:iSTS
,, ,_ '""'
/ /A memory .mapged ;Qbje\:;t .w:i, tp..igifen name. e.~i,$1::'s :alreasy.
printf ('Th~ n~m~d meinbry,maJ?p~·d·obj_ec;t ~f3 -.i?;li~~9Y; . .
existing\h',:·) ;· · c,: ..;::1 ·,.·, • . . ·.:,,.: :,,:,:·, ·
}
//Map the memory mapped object to Process 2's'addres.s. space
• <'' .:!'I' ' ,,,,. "'7 ·' > " .,

hChildMapView~ (LPTSTR) M.;ipViewOfFile (hCl:li;LdFil~MJff :: ·~·\ ,

FILE.'Mil?wRITE';'·iiReact'.:.wri'tJ\acc~sl
0, · -//t;'.t;P the Bntire :vi~~ · ··
4
··

o, .
0);
if (NULL== hChildMapy1ew)
{
printf ("Mapping of Memory mapped view Failed; Er:ror Code:
() ) ;
I /M~emory mapped view Creation failed. Return
return;
}
·~'
else

//Successfully created the memory mapped view.

//Print the start address of the mapped view
printf ("The memory mapped view starts at memory location 0x%08x\n", hChild-
MapView);
}

//Unmap the view

UnmapViewOfFile(hChildMapView);
//Close memory mapped object handle
CloseHandle(hChildFileMap);
return;
 Real-Time Operating System (RTOS) based Embedded System Design

The output of the above programs when run in the sequence, Process 1 is executed first and Process
2 is executed while Process 1 waits for the user input from the keyboard, is given in Fig. 10.19.

The Memory mapped object is mapped to the Virtual

address 0x00340000 of both the Processes

This reveals that using memory mapped objects with same name across multiple processes running
on the same system maps the object to the same virtual address space of the processes.
Reading and writing to a memory mapped area is same as any read write operation using pointers.
The pointer returned by the API call Map ViewOJFile can be used for this. The exercise of Read and
Write operation is left to the readers. Proper care should be taken to avoid any conflicts that may arise
due to the simultaneous read/write access of the shared memory area by multiple processes. This can be
handled by applying various synchronisation techniques like events, mutex, semaphore, etc.
For using a memory mapped object across multiple threads of a process, it is not required for all
I the threads of the process to create/open the memory mapped object and map it to the thread's virtual
address space. Since the thread's address space is part of the process's virtual address space, which
contains the thread, only one thread, preferably the parent thread (main thread) is required to create the
memory mapped object and map it to the process's virtual address space. The thread which creates the
memory mapped object can share the pointer to the mapped memory area as global pointer and other
threads of the process can use this pointer for reading and writing to the mapped memory area. If one
thread of a process tries to create a memory mapped object with the same name as that of an existing
mapping object, which is created by another thread of the same process, a new view of the mapping
object is created at a different virtual address of the process. This is same as one process trying to create
two views of the same memory mapped object©.

10.7.2 Message Passing

Message passing-is an (a)synchronous information exchange mechanism used for Inter Process/Thread
 Introduction to Embedded Systems

Communication. The major difference between shared memory and message passing technique is that, IF
through shared memory lots of data can be shared whereas only limited amount of info/data is passed A
through message passing. Also mes.sage passing is relatively fast and free from the synchronisation qt
overheads compared to shared memory. Based on the message passing operation between the processes, m
message passing is classified into Sc
I 0. 7.2.1 Message Queue Usually the process which wants to talk to another process posts the tb
message to a First-In-First-Out (FIFO) queue called 'Message queue', which stores the messages tem- ll
porarily in a system defined memory object, to pass it to the desired process (Fig. 10.20). Messages are tr
'VY
sent and received through send (Name of th_e.process to which the message is to besent,-message) and
receive (Name of the process from which the message is to be received, message) methods. The mes- tt
sages are exchanged through· a message queu~. The implementation of the message queu~, send and re-
ceive methods are OS kernel dependent. The Windows XP OS kernel maintains a single system l!lessage ti
queue and one process/thread (Process and threads are used interchangeably here, since thread ,is the
basic unit of process in windows) specific· message queue. A thread which wants to communicate with n
0
another thread posts the message to the system message queue. The kernel picks up the message from
the system message queue one at a time and examines the message for finding the destination thread and
then posts the message to the message queue of the corresponding thread. For posting a message to a a
n
thread's message queue, the kernel fills a message structure MSG and copies it to the message"queue of
the thread. The message structure MSG contains the handle of the process/thread for which the message q
is intended, the message parameters, the time at which the message is posted, etc. A thread can simply r
j
post a message to another thread and can continue its operation or it may wait for a response from the
r
thread to which the message is posted. ihe messaging mechanism is classified into synchronous and
(
asynchronous based on the behaviour of the message posting thread. In asynchronous messaging, the
message posting thread just posts the·message to the queue and it will not wait for an acceptance (return)
from the thread to which the message is posted, whereas in synchronous messaging, the thread which
posts a message enters waiting state and waits for the message result from the thread to which the mes-
sage is posted. The thread which invoked the send message becomes blocked and the scheduler will not
pick it up for scheduling. The PostMessage (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM

( Fig. 10.ZO) Concept of message queue based indirect messaging for IPC
 Real-Time Operating System (RTOS) based Embedded System Design

t, /Param) or PostThreadMessage (DWORD idThread, UINT Msg, WPARAMwParam, LPARAM lParam)

d API is used by a thread in Windows for posting a message to its own message queue or to the message
n queue of another thread. The PostMessage API does not always guarantee the posting of messages to
i, message queue. The PostMessage API will not post a message to the message queue when the mes-
sage queue is full. Hence it is recommended to check the return value of PostMessage API to confirm
the posting of message. The SendMessage (HWND hWnd, UINT Msg, WPARAMwParam, LPARAM
e
A
lParam) APJ call sends a message to the thread specified by the handle hWnd and waits for the callee
thread to process the message. The thread which calls the SendMessage API enters waiting state and
e
waits for the message result from the thread to which the message is posted. The thread which invoked
d
the SendMessage API call becomes blocked and the scheduler will not pick it up for scheduling.
The Windows CE operating system supports a special Point-to-Point Message queue implementa-
·-
tion. The OS maintains a First In First Out (FIFO) buffer for storing the messages and each process can
e
access this buffer for reading and writing messages. The OS also maintains a special queue, with single
e
message storing capacity, for storing high priority messages (Alert messages). The creation and usage
h
(1
of message queues under Windows CE OS is explained below.
The CreateMsgQueue(LPCWSTR lpszName, LPMSGQUEUEOPTIONS lpOptions) API call creates
d
a message queue or opens a named message queue and returns a read only or write only handle to the
a
:i message queue. A process can use this handle for reading or writing a message from/to of the message
f
queue pointed by the handle. The parameter lpszName specifies the name of the message queue. If this
e
parameter is NULL, an unnamed message queue is created. Processes can use the handle returned by the
y
API call if the message queue is created without any name. If the message queue is created as named
e
message queue, other processes can use the name of the message queue for opening the named message
d
queue created by a process. Calling the CreateMsgQueue API with an existing named message queue
e
as parameter returns a handle to the existing message queue. Under the Desktop Windows Operating
)
Systems (Windows 9x/XP/NT/2K), each object type (viz. mutex, semaphores, events, memory maps,
h
watchdog timers and message queues) share the same namespace and the same name is not allowed for
it
creating any of this. Windows CE kernel maintains separate narnespace for each and supports the same
t
,f
·{ name across different objects. The lpOptions parameter points to a MSGQUEUEOPTIONS structure
that sets the properties of the message queue. The member details of the MSGQUEUEOPTIONS struc-
ture is explained below.
typedef MSGQUEUEOPTIONS OS{
DWORD dwSize;
DWORD dwFlags;
DWORD dwMaxMessages;
DWORD cbMaxMessage;
B001 bReadAccess;
MSGQUEUEOPTIONS, FAR* LPMSGQUEUEOPTIONS, *PMSGQUEUEOPTIONS;
The members of the structure are listed below.

~Member·• lleshipti(ni
.. .
, .· . ' , ,:,., ,_.____./. '. ;,;,

\i~s1ze·
.;,~ ',,,., :,.~"~,. '

Specifie~ the size of the structure in bytes

':.of; ;~\:, ':,1¥:Iqt~QQM;~!Jq
· · · f ~ read, o(:set
:1¢ofupl;t¥ ev~~ ff
·--- --- ,:,,,,t,,,·, . . __ --,.".·,-.".·;.•,'·.•
 Introduction to Embedded Systems

dwMaxNkssages ·. Specifies tge maiimur11 m.rmb~r ofmessage~to qiie~eat ariy poirlt'of time. ~eUhis vaiuetozem th
to :sQec{f'r,i~BJ{~itcoh the nuhifiet df Pl¢\s/t?t~Rfq~~q,at,~~Y£~illtlif:fifit6: .. . . . :'
1{ fo
th
th
to
.Sp~~ill~& th6 t~a,~;~i{f~\,ce&~ tpJhyJ~ G
'.the queue. ~-en~FALSRtd ieqttest wri~~ac
al
On successful execution, the CreateMsgQueue API call returns a 'Read Only' or 'Write Only' handle G
to the specified queue based on the bReadAccess member of the MSGQUEUEOPTJONS structure Ip Op- b1
tions. If the queue with specified name already exists, a new handle, which points to the existing queue,
is created and a following call to GetLastError returns ERROR ALREADY_EXJSTS. If the function
fails it returns NULL. A single call to the CreateMsgQueue creates the queue for either 'read' or 'write'
access. The CreateMsgQueue API should be called twice with the bRead:Access member of the MS-
GQUEUEOPTIONS structure lpOptions set to TRUE and FALSE respectively in successive calls for
obtaining 'Read only' and 'Write only' handles to the specified message queue. The handle returning
by CreateMsgQueue API call is an event handle and, if it is a 'Read Only' access handle, it is signalled
by the message queue if a new message is placed in the queue. The signal is reset on reading the mes-
sage by ReadMsgQueue API call. A 'Write Only' access handle to the message queue is signalled when
the queue is no longer full, i.e. when there is room for accommodating new messages. Processes can
monitor the handles with the help of the wait functions, viz. WaitForSingleObject or WaitForMulti- 1
pleObjects, supported by Windows CE. The OpenMr;gQueue(HANDLE hSrcProc, HANDLE hMsgQ,
LPMSGQUEUEQPTjONS lpOptions) API call opens an existing named or unnamed message queue.
The parameter hSrcProc specifies the process handle of the process that owns the message queue and
hMsgQ specifies the handle of the existing message queue (Handle to the message queue returned by
the CreateMsgQueue function). As in the case of CreateMsgQueue, the lpOptions parameter points to a
MSGQUEUEOPTIONS structure that sets the properties of the message queue. On successful execution
the OpenMsgQueue API call returns a handle to the message queue and NULL if it fails. Normally the
OpenMsgQueue API is used for opening an unnamed message queue. The WriteMsgQueue(HANDLE
hMsgQ, LPVOID lpBuffer, DWORD cbDataSize, DWORD dwTimeout, DWORD dwFlags) API call is
used for writing a single message to the message queue pointed by the handle hMsgQ. lpBuffer points to
a buffer that contains the message to be written to the message queue. The parameter cbDataSize speci-
fies the number of bytes stored in the buffer pointed by IpBuffer, which forms a message. The parameter
dwTimeout specifies the timeout interval in milliseconds for the message writing operation. A value of
zero specifies the write operation to return immediately without blocking if the write operation cannot
succeed. If the parameter is set to INFINITE, the write operation will block until it succeeds or the mes-
sage queue signals the 'write only' handle indicating the availability of space for posting a message.
The dwFlags parameter sets the priority of the message. If it is set to MSGQUEUE_MSGALERT, the
message is posted to the queue as high priority or alert message. The Alert message is always placed in
the front of the message queue. This function returns TRUE if it succeeds and FALSE otherwise.
The ReadMsgQueue(HANDLE hMsgQ, LPVOID lpBuffe1; DWORD cbBufferSize, LPDWORD
lpNumberOfBytesRead, DWORD dwTimeout, DWORD* pdwFlags) API reads a single message from
the message queue. The parameter hMsgQ specifies a handle to the message queue from which the
message needs to be read. lpBuffer points to a buffer for storing the message read from the queue. The
parameter cbBufferSize specifies the size of the buffer pointed by lpBujfer, in bytes. lpNumberOJBytes-
Read specifies the number of bytes stored in the buffer. This is same as the number of bytes present in
 Real-Time Operating System (RTOS) based Embedded System Design

the message which is read from the message queue. dwTimeout specifies the timeout interval in mil-
liseconds for the message reading operation. The timeout values and their meaning are same as that of
the write message timeout parameter. The dwFlags parameter indicates the priority of the message. If
the message read from the message queue is a high priority message (alert message), dwFlags is set
to MSGQUEUE MSGALERT. The function returns TRUE if it succeeds and FALSE otherwise. The
GetMsgQueuelnfo (HANDLE hMsgQ, LPMSGQUEUEINFO lplnfo) API call returns the information
about a message queue specified by the handle hMsgQ. The message information is returned in a MS-
GQUEUEINFO structure pointed by lplnfo. The details of the MSG.QUEUEJNFO structure is explained
below.
MSGQUEUEINFO{
dwSize;
.dwFlags.;
DWORD dwMaxMessages;
DWORD cbMaxMessage;
· DWORD dwCurrentMessage~; .
DWORD dwMaxQu.'eueMessages;
WORD wNumReaders;
· WORD wNumWrii:ers;
MSGQUEUEINFO, *PMSGQUEUEINFO, FAR* LPMSGQUEUEINFO;
· The member variable details are listed below.

;d~MaxMessages Specifi~s the maximum number ofmessages to queue at any .point of time. This reflects,•
· the MSGQUEUEOPTIONS. dwMaxMes.sages_ valu~ passed.when the message qu'eµe;is
cr~ated with Crea~e:MsgQueue API call.. . .
e maxiniJim
EfiEOPJ!iofis:Eb
. f~at~MsgQueu~iPI 6~ll:
dwCurrentMessages Specifies the number of messages cunently existing in the specified message queue.
dwMaxQueueMessages Specifies max.irnuni number of messages tha:fhave·ever been in the queue at one time.
,,, , 0,

wNumReaders Specifies the number of readers (processes which opened the message queue for reading)
subscribed to the message queue for reading .

wNumWriters .Specifies the number of writers (processes which opened the i;nessage queue for writing)
to
subscribed the message queue for writing.
The GetlvfsgQueuelnfo API call returns TRUE if it succeeds and FALSE otherwise. The
CloseMsgQueue(HANDLE hMsgQ) API call closes a message queue specified by the handle hMsgQ.
If a process holds a 'read only' and 'write only' handle to the message queue, both should be closed for
closing the message queue.
'Message queue' is the primary inter-task communication mechanism under VxWorks kernel. Mes-
sage queues support two-way communication of messages of variable length. The two-way messaging
 Introduction to Embedded Systems

between tasks can be implemented using one message queue for incoming messages and another one
for outgoing messages. Messaging mechanism can be used for task-to task and task to Interrupt Service
Routine (ISR) communication. We will discuss about the VxWorks' message queue implementation in
a separate chapter.
10. 7.2.2 Mailbox Mailbox is an alternate form of 'Message queues' and it is used in certain Real-
Time Operating Systems for IPC. Mailbox technique for IPC in RTOS is usually used for one way mes-
saging. The task/thread which wants to send a message to other tasks/threads creates a mailbox for post-
ing the messages. The threads which are interested in receiving the messages posted to the mailbox by
the mailbox creator thread can subscribe to the mailbox. The thread which creates the mailbox is known·
as 'mailbox server' and the threads which subscribe to the mailbox are known as 'mailbox clients'.
The mailbox server posts messages to the mailbox and notifies it to the clients which are subscribed to
the mailbox. The clients read the message from the mailbox on receiving the notification. The mailbox
creation, subscription, message reading and writing are achieved through OS kernel provided API calls.
Mailbox and message queues are same in functionality. The only difference is in the number of mes-
sages supported by them. Both of them are used for passing data in the form of message(s) from a task
to another task(s). Mailbox is used for exchanging a single message between two tasks or between an In-
terrupt Service Routine (ISR) and a task. Mailbox associates a pointer pointing to the mailbox and a wait
list to hold the tasks waiting for a message to
/
appear in the mailbox. The implementation
of mailbox is OS kernel dependent. The Mi-
croC/OS-II implements mailbox as a mecha-
nism for inter-task communication. We will
discuss about the mailbox based IPC imple- "O

mentation under MicroC/OS-II in a latter

chapter. Figure 10.21 given below illustrates
0
"' -
the mailbox based IPC technique.
'
10.7.2.3 Signalling Signallingisaprim-
itive way ofcommunication between process-
es/threads. Signals are used for asynchronous Mail box
notifications where one process/thread fires
a signal, indicating the occurrence of a sce-
nario which the other process(es)/thread(s)
is waiting. Signals are not queued and they
do not carry any data. The communication El(1)
mechanisms used in RTX5 l Tiny OS is an "':,,
ti)

(JO

example for Signalling. The os send_signal (1)

kernel call under RTX 51 sends a signal from

one task to a specified task. Similarly the
os~wait kernel call waits for a specified sig-
nal. Refer to the topic 'Round Robin Sched-
uling' under the section 'Priority based
scheduling' for more details on Signalling in
RTX51 Tiny OS. The VxWorks RTOS kernel ( Fig. 10.21). Concept of Mailbox based indirect messaging
also implements 'signals' for inter process forIPC
. -
 Real-Time Operating System (RTOS) based Embedded System Design

ne communication. Whenever a specified signal occurs it is handled in a signal handler associated with the
ce signal. We will discuss about the signal based IPC mechanism for VxWorks' kernel in a later chapter.
m
10.7.3 Remote Procedure Call (RPC) and Sockets
ll- Remote Procedure Call or RPC (Fig. 10.22) is the Inter Process Communication (IPC) mechanism used
:s-. by a process to call a procedure of another process running on the same C:PU or on a different CPU
3t- which is interconnected in a network. In the object oriented language temrinology RPC is also known
by as Remote Invocation or Remote Method Invocation (RMI). RPC is mainly used for distributed appli-
vn cations like client-server applications. With RPC it is possible to communicate over a heterogeneous
,,
~ . network (i.e. Network where Client and server applications are running on different Operating systems).
··•
to The CPU/process containing the procedure which needs to be invoked remotely is known as server. The
ox CPU/process which initiates an RPC request is known as client.
ls.
is-
sk
n-
ait
Procedure

Processes running on different CPUs which are networked

Procedure

Processes running on same CPU

[Fig. 10.22) Concept of Remote Procedure Call (RPC) for IPC

It is possible to implement RPC communication with different invocation interfaces. In order to

make the RPC communication compatible across all platfonns it should stick on to certain standard
forn1ats. Interface Definition Language (IDL) defines the interfaces for RPC. Microsoft Interface Defi-
nition Language (MIDL) is the IDL implementation from Microsoft for all Microsoft platforms. The
RPC communication can be either Synchronous (Blocking) or Asynchronous (Non-blocking). In the
Synchronous communication, the process which calls the remote procedure is blocked until it receives
a response back from the other process. In asynchronous RPC calls, the calling process continues its
J
execution while the remote process perfonns the execution of the procedure. The result from the remote
procedure is returned back to the caller through mechanisms like callback functions.
 Introduction to Embedded Systems

On security front, RPC employs authentication mechanisms to protect the systems against vulner-
abilities. The client applications (processes)should authenticate themselves with the server for getting
access. Authentication mechanisms like IDs, public key cryptography (like DES, 3DES), etc. are used
by the client for authentication. Without authentication, any client can access the remote procedure. This
may lead to potential security risks.
Sockets are used for RPC communication. Socket is a logical endpoint in a two-way communication
link between two applications _running on a network. A port number is associated with a socket so that
the network layer of the communication channel can deliver the data to the designated application.
Sockets are of different types, namely, Internet sockets (INET), UNIX sockets, etc. The INET socket
works on internet communication protocoL TCP/IP, UDP, etc. are the communication protocols used by
INET sockets. INET sockets are classified into:
l. Stream sockets
2. Datagram sockets
Stream sockets are connection oriented and they use TCP to establish a reliable connection. On the
other hand, Datagram sockets rely on UDP for establishing a connection. The UDP connection is ume-
liable when compared to TCP. The client-server communication model uses a socket at the client side
and a socket at the server side. A port number is assigned to both of these sockets. The client and server
should be aware of the port number associated with the socket. In order to start the communication, the
client needs to send a connection request to the server at the specified port number. The client should
be aware of the name of the server along with its port number. The server always listens to the specified
port number on the network. Upon receiving a connection request from the client, bc3:sed on the success
of authentication, the server grants the _connection request and a communication channel is established
between the client and server. The client uses the host name and port number of server for sending re-
quests and server uses the client's name and port number for sending responses.
If the client and server applications (both processes) are running on the same CPU, both can use the
same host name and port number for communication. The physical communication link between the
client and server uses network interfaces like Ethernet or Wi-Fi for data communication. The underlying
implementation of socket is OS kernel dependent. Different types of OSs provide different socket inter-
faces. The following sample code illustrates the usage of socket for creating a client application under
Windows OS. Winsock (Windows Socket 2) is the library implementing socket functions for Win32.
#include <stdi0. h> . i
I.
#include "winsock2.hn
//Specify the server addre~s
#define SERVER "172.168.0.1"
//SpeQify the server port
#define PORT 5000
int buflength = 100;
char *sendbuf = "Hi from Client";
char buffei[buflength];
_void main () {
//*******************************************************'*
// Initialize Winsock
WSADATA wsaData;
if tWSAStartup(MAKEWORD(2,2), &wsaData) == NO_ERROR)
printf ("Win sock Initialisation succeeded... \n");
 Real-Time Operating System (RTOS) based Embedded System Design

r- else
.g
:d printf(nWinsock InitialiS~ti6n failed .. \n");
IS return;
}
I/***********·*·*************************·*·*****·**************
it / / Create a scitKET for connecting fro
A''°•'•' .,. O • ,;!,••••"
,,•_:•::--
server
;
'7 •·,_; "• '"';/', •••:• ; S

sdi:::KET M. scicl-i:~t · · · ·. ·· · · · ·
'l. . . .-••~ ''Y y ·, ···:• ·: ,. ·.:.. . < ". .: .. . . ·. . .• .
=

~' '~\; ; ;~; jt,l: :~(~q~::;: :~;)K{ '. ~-

. MyS0cket socket"(AF·'[NET;: S,OCK 'STREAM(;TPPROTO ·TCP);

l' ' "

.return;
le ;}
:e1ise
le f
, . ,prin:tf.('\Sqc,c·essfµll,y crea1:ed tti.e •socket ... \n,,) ;_ .... ·. ·.
Le ·.. ; //*)* '!<.*,* t).1 ·s:ffJ}t*Jr~~{*
* t :,/***{-tr~*:~·*'-".*;*:~{~/:***** V tt>f~ *+':7' t t*
ld >h. /(Se,1;:, _tf!~::~S?:.~.J<~t. :t,yp;e_, IJ? a~~l'.'.~1=315.!r"\Il,c:\::_por.!.·'?frJ:.he server
:so.Ckaddr _:fr1: :$er;v:efParams; ,. .. . . .
:d
'. > Serv.erParam~;sin
lc~J~;~. ::,,"·•~!-. .• t:.
fa:rnily
'.:':··' _;'<::0::-v: -Ii-;,-. ·,,'.,,,. --·'.: ,, •
·~ AF INET;· : , ',...
,,;_.-· .. - !'::7 ... -.,· --~_, ·'
f\ ; 'Ser.vei.Paf.a'ins ~ ~ih addr. s addr. ~ . in.et addr ( SERVER ) ;
:d :~:-,1·~~-"';'._ ··::-:.•-_ ,:--'~L;-i~y:,__·;~), >~:-).{~";·_>::----~·---:, _ ~\:, ---~--- ~:_ t· \" _,~ •.. --r_--'<-·:/S-:- -·'. ,/ <°-> ·. ,~-- - ·~
.,. , S~rveiParams: 'sin port = htons ( POf'T. ) f , · . , ·
1}·****'*'* *;:'.*¼i~*\. -;*·*** ** ** ** ** *** * **l*'h ****** ** ****,* *** ***'!'
?i',:-!l; Coi1nect?tb: server;
1e :r(,· ,if (Lconnect{ MySocket';. (SOCKADDR*) '& ServerParams,' sizeof (ServerPararns).
Le :.C' 'SOCKET~~RROR) {
tg ,£:, : .printf ( '~Connecting to Server _failed... \n'' ) ;
r- WSAC1eanup (} ;
return;

else

printf ("Successfully Connected to the server .. ,\n");

//*********************************************************
// Send command to server
if (send (MySocket, sendbuf, (int) strlen (sendbuf), 0 )
== SOCKET_ERROR) {
printf ("Sending data to server failed ... \n");
closesocket(MySocket);
WSACleanup () ;
return;

else

printf("Successfully sent command to server. .. \n");

 . Introduction to Embedded Systems

eac
wh
ces
is t
Ho
res,
by
iss1
sec
cor

10
10.

The above application tries to colltlect to a server machine with IP address 172.168.0.1 and port num-
ber 5000. Change the values of SERVER and PORT to connect to a machine with different IP address
and port number. If the connection is success, it sends the data "Hi from Client" to the server and waits
for a response from the server and finally terminates the connection.
Under Windo\Ys, the socket function library Winsock should be initiated before using the socket
related functions. The function WSAStartup performs this initiation. The socket0 function call creates
a socket. The socket type, connection type and protocols for communication are the parameters for
socket creation. Here the socket type is !NET (AFJNET) and connection type is stream socket (SOCK_
STREAM). The protocol selected for communication is TCP/IP (JPPROTO_TCP). After creating the
socket it is connected to a server. For connecting to server, the server address and port number should be
indicated in the connection request. The sockaddr_in structure specifies the socket type, IP address and
port of the server to be connected to. The connect 0 function connects the socket with a specified server.
If the server grants the connection request, the connect {) function returns success. The send0 function
is used for sending data to a server. It takes the socket name and data to be sent as parameters. Data from
server is received using the function call recv(). It takes the socket name and details of buffer to hold the
received data as parameters. The TCP/IP network stack expects network byte order (Big Endian: Higher
order byte of the data is stored in lower memory address location) for data. The function htons0 con-
verts the byte order of an unsigned short integer to the network order. The closesocket0 function closes
the socket connection. On the server side, the server creates a socket using the function socket0 and
binds the socket with a port using the bind0 function. It listens to the port bonded to the socket for any
incoming connection request. The function listen0 performs this. Upon receiving a connection request,
the server accepts it. The function accept() performs the accepting operation. Now the connectivity is
established. Server can receive and transmit data using the function calls recv() and send() respectively.
The implementation of the server application is left to the readers as an exercise. I
:i

In a multitasking environment, multiple processes run concurrently (in pseudo parallelism) and share the
system resources. Apart from this, each process has its own boundary wall and they communicate with
 Real-Time Operating System (RTOS) based Embedded System Design

each other with different lPC mechanisms including shared memory and variables. Imagine a situation
where two processes try to access display hardware connected to the system or two processes try to ac-
cess a shared memory area where one process tries to write to a memory location when the other process
is trying to read from this. What could be the result in these scenarios? Obviously unexpected results.
How these issues can be addressed? The solution is, make each process aware of the access of a shared
resource either directly or indirectly. The act of making processes aware of the access of shared resources
by each process to avoid conflicts is known as 'Task/Process Synchronisation'. Various synchronisation
issues may arise in a multitasking environment if processes are not synchronised properly. The following
sections describe the major task communication synchronisation issues observed in multitasking and the
commonly adopted synchronisation techniques to overcome these issues.

10.8.1 Task Communication/Synchronisation Issues

10.8.1.1 Racing Let us have a look at the following piece of code:
:Ainclude <wi:ni;l.o,;;S;~ h> , ' ... ·
tl¾~e1·qa;·'.,?i14.~IJ/t:· . ::.:··<;.,. :-. ·· . :::f.·...: i ·;ff . ·_.· .....· :, .·~ ··.~;:::;:j!\

·t<"s~;'}:r+t):;·
.; . i,t\ · · · ·
>:{~·,x. ;;t\> ~

;;\t(j; it·;(Bufii:r rlt1::;~:D)

~,i;;,
,,•,'
, ·· counter'++···
' ;'' ! . . , ;
/· ·
.;:~,; ,··
}
//*****~***********************************~************~*********
;j I )Process B
void Process B(void)
int j;
for (j =5; j<lO; j++)

if (Buffer[j] > 0)
counter++;
' }
}
. //*******~*****•**********************f***************************
//Main Thread .
. int main () {
DWORD id;
 Introduction to Embedded Systems

From a programmer perspective the value of counter will be 10 at the end of execution of processes
A & B. But 'it need not be always' in a real world execution of this piece of code under a multitasking
kernel. The results depend on the process scheduling policies adopted by the OS kernel. Now let's dig
into the piece of code illustrated above. The program statement counter++; looks like a single statement ").

from a high level programming language ('C' language) perspective. The low level implementation of
this statement is dependent on the underlying processor instruction set and the (cross) compiler in use. (!
The low level implementation of the high level program statement counter++; under Windows XP op-
erating system running on an Intel Centrino Duo processor is given below. The code snippet is compiled ir
with Microsoft Visual Studio 6.0 compiler. b,
Cl
n
1
0
At the processor instruction level, the value of the variable counter is loaded to the Accumulator ti
register (BAX register). The memory variable counter is represented using a pointer. The base pointer ~
register (EBP register) is used for pointing to the memory variable counter. After loading the contents ~
(
of the variable· counter to the Accumulator, the Accumulator content is incremented by one using the
add instruction. Finally the content of Accumulator is loaded to the memory location which repre- t
l
sents the variable counter. Both the processes Process A and Process B contain the program statement I.

counter++; Translating this into the machine instruction.

Imagine a situation where a process switching (context switching) happens from Process A to Process
B when Process A is executing the counter++; statement. Process A accomplishes the counter+ · state-
ment through three different low level instructions. Now imagine that the process switching happened at
the point where Process A executed the low level instruction, 'mov eax,dword ptr [ebp-4]' and is about
to execute the next instruction 'add eax,l '. The scenario is illustrated in Fig. 10.23.
Process B increments the shared variable 'counter' in the middle of the operation where Process A
tries to increment it. When Process A gets the CPU time for execution, it starts from the point where
it got intermpted (If Process B is also using the same registers eax and ebp for executing counter++,·
 Real-Time Operating System (RTOS) based Embedded System Design

tg
tg
1t
)f
e.
)-

:d instruction, the original content of these registers will be saved as part of the context saving and it will
be retrieved back as part of context retrieval, when process A gets the CPU for execution. Hence the
content of eax and ebp remains intact irrespective of context switching). Though the variable counter is
incremented by Process B, Process A is unaware of it and it increments the variable with the old value.
This leads to the loss of one increment for the variable counter. This problem occurs due to non-atomict
operation on variables. This issue wouldn't have been occurred if the underlying actions corresponding
>r to the program statement counter++; is finished in a single CPU execution cycle. The best way to avoid
this situation is make the access and modification of shared variables mutually exclusive; meaning when
ts one process accesses a shared variable, prevent the
Le - other processes from accessing it. We will discuss
this technique in more detail under the topic 'Task
lt Synchronisation techniques' in a later section of
this chapter.
· To summarise, Racing or Race condition is the
:situation in which multiple processes compete
(race) each other to access and manipulate shared
data concurrently. In a Race condition the final val-
ue of the shared data depends on the process which
acted on the data finally.
:s 10.8.1.2 Deadlock A race condition produces
incorrect results whereas a deadlock condition cre-
ates a situation where none of the processes are able
to make any progress in their execution, resulting
in a ~et of deadlocked processes. A situation very
similar to our trafficjam issues in a junction as il-
lustrated in Fig. 10.24.
I
(fig.lp.24) D~iidlt>ck visualisation
t Atomic Operation: Operations which are non-interruptible.
 Introduction to Embedded Systems

In its simplest form 'deadlock' is the con-

dition in which a process is waiting for a re-
source held by another process which iswait-
ing for a resource held by the first process
(Fig. 10.25). To elaborate: Process A holds
a resource x and it wants a resource y ·held
by Process B. Process B is currently holding
resource y and it wants the resource x which ,ij~;U,Q{?,~,
is currently held by Process A. Both hold the
respective resources and they compete each
other to get the resource held by the respective processes. The result of the competition is 'deadlock'.
None of the competing process will be able- to access the resources held by other processes since they
are locked by the respective processes (If a mutual exclusion policy is iITiplemented for shared resource
access, the resource is locked by the process which is currently accessing it). ·
The different conditions favouring a deadlock situation are listed below.
Mutual Exclusion: The criteria that only one process can hold a resource at a time. Meaning processes
should access shared resources with mutual exclusion. Typical example is the accessing of display
hardware in an embedded device.
Hold and Wait: The condition in which a process holds a shared resource by acquiring the lock control-
ling the shared access and waiting for additional resources held by other processes.
No Resource Preemption: The criteria that operating system cannot take back a resource from a
process which is currently holding it and the resource can only be released voluntarily by the process
holding it.
Circular Wait: A process is waiting for a resource which is currently held by another process which in
tum is waiting for a resource held by the first process. In general, there exists a set of waiting pr~cess
PO, Pl ... Pn with PO is waiting for a resource held by Pl and Pl is waiting for a resource held by"P0,
... , Pn is waiting for a resource held by PO and PO is waiting for a resource held by Pn and so on ... This
forms a circular \Vait queue.
a
'Deadlock' is result of the combined occurrence of these four conditions listed above. These condi~
: tions are first described by E.G. Coffman in 1971 and it is popularly known as Coffman conditions;
Deadlock Handling A smart OS may foresee the deadlock condition and will act proactively to
avoid such a situ~tion. Now if a deadlock occ:urred, how the OS responds to it? The reaction to deadlock
condition by OS is nonuniform. The OS may adopt any of the following techniques to detect and prevent
deadlock conditions.
Ignore Deadlocks: Always assume that the system design is deadlock free. This is acceptable for the
reason the cost of removing a deadlock is large compared to the chance of happening a deadlock. UNIX-
is an example for an OS following this principle. A life critical system cannot pretend that it is deadlock
free for any reason.
Detect and Recover: This approach suggests the detection of a deadlock situation and recovery from
it. This is similar to the deadlock condition that may arise at a traffic junction. When the vehicles from
different directions compete to cross the junction, deadlock (traffic jam) condition is resulted. Once a
 Real-Time Operating System (RTOS) based Embedded System Design

deadlock (traffic jam) is happened at the junction, the only solution is to back up the vehicles from one
direction and allow the vehicles from opposite direction to cross the junction. If the traffic is too high,
lots of vehicles may have to be backed up to resolve the traffic jam. This technique is also known as
'back up cars' technique (Fig. 10.26).

Operating systems keep a resource graph in their memory. The resource graph is updated on each
resource request and release. A deadlock condition can be detected by analysing the resource graph by
graph analyser algorithms. Once a deadlock condition is detected, the system can terminate a process or
preempt the resource to break the deadlocking cycle.
Avoid Deadlocks: Deadlock is avoided by the careful resource allocation techniques by the Operating
System. It is similar to the traffic light mechanism at junctions to avoid the traffic jams.
Prevent Deadlocks: Prevent the deadlock condition by negating one of the four conditions favouring
the deadlock situation.
• Ensure that a process does not hold any other resources when it requests a resource. This can be
achi~ved by implementing the following set of rules/guidelines in allocating resources to pro-
cesses.
1. A process must request all its required resource and the resources should be allocated before
the process begins its execution.
2. Grant resource allocation requests from processes only if the process does not hold a resource
currently.
 Introduction to Embedded Systems

• Ensure that resource preemption (resource releasing) is possible at operating system level. This
can be achieved by implementing the following set of rules/guidelines in resources allocation and
releasing.
1. Release all the resources currently held by a process if a request made by the process for a new
resource is not able to fulfil immediately.
2. Add the resources which are preempted (released) to a resource list describing the resources
which the process requires to complete its execution.
3. Reschedule the process for execution only when the process gets its old resources and the new
resource which is requested by the process.
Imposing these criterions may introduce negative impacts like low resource utilisation and starvation
of processes.
Livelock The Livelock condition is similar to the deadlock condition except that a process in livelock
condition changes its state with time. While in deadlock a process enters in wait state for a resource and
continues in that state forever without making any progress in the execution, in a livelock condition a
process always does something but is unable to make any progress in the execution completion. The
livelock condition is better explained with the real world example, two people attempting to cross each
other in a narrow corridor. Both the persons move towards each side of the corridor to allow the opposite
person to cross. Since the corridor is narrow, none of them are able to cross each other. Here both of the
persons perform some action but still they ·are unable to achieve their target, cross each other. We will
make the livelock, the scenario more clear in a later section-The Dining Philosophers' Problem, of this
chapter.
Starvation In the multitasking context, starvation is the condition in which a process does not get
the resources required to continue its execution for a long time. As time progresses the process starves
on resource. Starvation may arise due to various conditions like byproduct of preventive measures of
deadlock, scheduling policies favouring high priority tasks and tasks with shortest execution time, etc.
1Q.8. I .3 The Dining Philosophers' Problem The 'Dining philosophers 'problem' is an interest-
ing example for synchronisation issues in resource utilisation. The terms 'dining', 'philosophers', etc.
may sound awkward in the operating system context, but it is the best way to explain technical things
abstractly using non-technical terms. Now coming to the problem definition:
Five philosophers (It can be 'n'. The number 5 is taken for illustration) are sitting around a round
table, involved in eating and brainstorming (Fig. 10.37). At any point of time each philosopher will be
in any one of the three states: eating, hungry ot brainstorming. (While eating the philosopher is not in-
volved in brainstorming and while brainstorming the philosopher is not involved in eating). For eating,
each philosopher requires 2 forks. There are only 5 forks available on the dining table ('n' for 'n' number
of philosophers) and they are arranged in a fashion one fork in between two philosophers. The philoso-
pher can only use the forks on his/her immediate left and right that too in the order pickup the left fork
first and then the right fork. Analyse the situation and explain the possible outcomes of this scenario.
Let's analyse the various scenarios that may occur in this situation.
Scenario 1: All the philosophers involve in brainstorming together and try to eat together. Each philoso-
pher picks up the left fork and is unable to proceed since two forks are required for eating the spaghetti
present in the plate. Philosopher 1 thinks that Philosopher 2 sitting to the right of him/her will put the
fork down and waits for it. Philosopher 2 thiriks that Philosopher J sitting to the right of htm/her will
 Real-Time Operating System (RTOS) based.Embedded System Design

s
d

V '
,;;-

11

k
i
a
"
v

1
"'"'
;!

s
0
t
.;

s put the fork down and waits for it, and so o~. This forms a circular chain...of un-granted requests. If the
f philosophers continue in this state waiting for the fork from the philosopher sitting to the right of each,
they will not make any progress in eating and this will result in starvation of the philosophers and
deadlock.
Scenario 2: All the philosophers start brainstorming together. One of the philosophers is hungry and he/
she picks up the left fork. Whell the philosopher is about to pick up the right fork, the philosopher sitting.
to his right also become hungry and tries to grab the left fork whic~ is the right fork of his neighbouring
philosopher who is trying to lift it, resulting in a 'Race condition' ..
Scenario 3: All the philosophers involve in brainstorming together and try to eat together. Each philoso-
pher picks up the left fork and is unable to proceed, since two forks are required for eating the Bpaghetti
present in the plate. Each of them anticipates that the adjacently sitting philosopher will put his/her fork
down and waits for a fixed duration arid after this puts the fork down. Each of them again tries to lift the
fork after a fixed duration oftime. Since all philosophers are trying to lift the fork at the same time, none
of them will be able to grab two forks. This condition leads to livelock and starvation of philosophers,
where each philosopher tries to do something, but they are unable to make any progress in achieving
.the target.
Figure 10.28 illustrates these scenarios.
Solution: We need to find out alternative solutions to avoid the.deadl9ck, livelock, racing and starva-
tion condition that may aris~ due to the concurrent afcess of forks by philosophers. This situation can be
handled in many ways by allocating the forks in different allocation techniques including Round Robin
allocation, FIFO allocation,1 etc. But,'the requirement is that the solution,should be optimal, avoiding
 Introduction to Embedded Systems

(a) (b)

I
(c)

( F~g.10.28) The''~l!al:~;f~~!7;e~'.:!~ ~he 'Dfoing fhilq~~phers pro~lem' (a) Sfarvc1..ion and Deadlock (b) Racing
(c:)'liive:lockanclSta:rva'.tfon · ' . . . · .· •······ . . · ·. ·

deadlock and starvation of the philosophers and allowing maximum number of philosophers to eat at a
time. One solution that we could think of is:
• Imposing rules in accessing the forks by philosophers, like: The philosophers should put down the
fork he/~he already have in hand (left fork) after waiting for a fixed duration for the second fork
(right-fork) and should wait for a fixed time before making the next attempt.
This solution works fine to some extent, but, if all the philosophers try to lift the forks at the same
1
time, a livelock situation is resulted. ,i i •

Another solution which gives maximum conc.;urren<:ythat can be thought of is each philosopher ac-
quires a semaphore (mutex) before picking up any fork. When a philosopher feels hungry he/she checks
whether the philosopher sitting to the left and right of him is, already using the fork, by checking the state
\
 Real-Time Operating System (RTOS) based Embedded System Design

of the associated semaphore. If the forks are in use by the neighbouring philosophers, the philosopher
waits till the forks are available. A philosopher when finished eating puts the forks down and informs
the philosophers sitting to his/her left and right, who are hungry (waiting for the forks), by signalling
the semaphores associated with the forks. We will discuss about semaphores and mutexes at a latter sec-
tion of this chapter. In the operating system context, the dining philosophers represent the processes and
forks represent the resources. The dining philosophers' problem is an analogy of processes competing
for shared resources and the different problems like racing, deadlock, starvation and Iivelock arising
from .the comp~tition.
10. 8. 1.4 Producer-Consumer/Bounded Buffer Problem Producer-Consumer problem is a
common data sharing problem where two processes concurrently ac~ess a shared buffer with fixed size.
A thread/process which produces data is called 'Producer thread/process' and a thread/process which
consumes the data produceq. by a. producer thread/process is known as 'Consumer thread/process'.
Imagine a siru.ation where the producer thread keeps on producing data and puts it into the buffer and the
consumer thread keeps on consuming the data from the buffer and there is no synchronisation between
the two. There may be chances where in which the producer produces data at a faster rate than the rate at
which it is consumed by the consumer. This will lead to 'buffer overrun' where the producer tries to put
data to a full buffer. If the consumer consumes data at a faster rate than the rate at 'Yhich it is produced
by the producer, it will lead to the situation 'biiffer under-run' in which the consumer tries to read from
an empty buffer. Both of these conditions will lead to inaccurate data and data loss. The following code
snippet illustrates the producer-consumer problem
,. 'bit include· <windows. h>
• 1• • . •

',-~
(;;#fnclude
t. -~., \. .
<s.tdio.
.
ti>
'\#define N ·20 I /Define buffer size as 20
tint buffer[Nf; //Sha'.ied ":r:;Uffer for p{opuCeC& co~s.urrier ·· .... ·• . . . . .· ..·
k1 l** * * ** * ** t ** l* *** * * *t*/* *************+*,:id.**)**:.****'"'****/****·**-!<.**'***
·!/./
~<,\' .
/Producer thread · · ··
itvoid
u
producer- thread.
(void)
int x;
while (true) {
for(x=O;x<N;x++)
{
//Fill buffer with random data
buffer[x]= rand(}%1000;
printf(~Produced: Buffer [%ct] %4d\n", x,
buffer[x]);
Sleep(25);
}

(: )
~//*******************************************************************
l(/C~nsumer thread
· ~.void consumer thread (void).
·r
~··
r·.
int y=O,value;
while(true) {
f
for (y=O; y<N; y++)
i":f, \
 Introduction to Embedded Systems

value=buffer[y]i
("Consumed Buffer [%di %4d\n", y, value);
(20) ;

I/******·*************************************************************
//Main Thread
'int ()
l
DW.ORD thread.:_id;
t/Create Producer thread
Create Thread (NULL, 0, ·
(LPTHREAD_START ROUTINE)producer_thread,
NULL,0,&thre~d_id);
//-Create Consumer thread
CreateThread(NULL,0,
(LPTHREAD_START_:,ROUTINE)consum,;:r_
NULL,0, id);
//Wait for some time and exit
( 5 00) ; C
return 0;
1
11
Here the 'producer thread' produces random numbers and puts it in a buffer of size 20. If the 'producer
n
thread' fills the buffer fully it re-starts the filling of the buffer from the bottom. The 'consumer thread'
ti
consumes the data produced by the 'producer thread'. For consuming the data, the 'consumer thread'
ti
reads the buffer which is shared with the 'producer thread'. Once the 'consumer thread' consumes all the
1
data, it starts consuming the data from the bottom of the buffer. These two threads run independently and I]
are scheduled for execution based on the scheduling policies adopted by the OS. The different situations
that may arise based on the scheduling of the 'producer thread' and 'consumer thread' is listed below.
c
r
1. 'Producer thread' is scheduled more_ frequently than the 'consumer thread': There are chances for
C
overwriting the data in the buffer by the 'producer thread'. This leads to inaccurate data.
2. Consumer thread' is scheduled more frequently than the 'produ_cer thread': There are chances for
readiqg the old data in the buffer again by the 'consumer thread'. This will also lead to inaccurate
data.
The output of the above program when executed on a Windows XP machine is shown in Fig. 10.29.
The output shows that the consumer thread runs faster than the producer thread and most often leads
to buffer under-run and thereby inaccurate data.
Note
It should be noted that the scheduling of the threads 'producer_thredd'-,anq 'consumer_thread' is OS
kernel scheduling policy dependent and you may not get the same output 'all the time when you run
this piece of code in Windows XP.
The producer-consumer problem can be rectified in various methods. One simple solution is the
'sleep and wake-up'. The 'sleep and wake-up' can be implemented in various process synchronisation
techniques like semaphores, mutex, monitors, etc. We will discuss it in a latter section of this chapter.
 Real-Time Operating System (RTOS) based Embedded System Design

10.8.1.S Readers-Writers Problem The Readers-Writers problem is a common issue observed

in processes competing for limited shared resources. The Readers-Writers problem is characterised by
multiple processes trying to read and write shared data concurrently. A typical real-world example for
i' the Readers-Writers problem is the banking system where one process tries to read the account informa-
j'
tion like available balance and the other process tries to update the available balance for that account.
le This may result in inconsistent results. If multiple processes try to read a shared data concurrently it
td may not create any impacts, whereas when multiple processes try to write and read concurrently it will
1S
definitely create inconsistent results. Proper synchronisation techniques should be applied to avoid the
readers-writers problem. We will discuss about the various synchronisation techniques in a later section
Dr
of this chapter.
or 10.8.1. 6 Priority Inversion Priority inversion is the byproduct of the combination of blocking
.te based (lock based) process synchronisation and pre-emptive priority scheduling. 'Priority inversion'
is the condition in which a high priority task needs to wait for a low priority task to release a resource
9. which is shared between the high priority task and the low priority task, and a medium priority task
ds which doesn't require the shared resource continue its execution by preempting the low priority task
(Fig. 10.30). Priority based preemptive scheduling technique ensures that a high priority task is always
executed first, whereas the lock based process synchronisation mechanism (like mutex, semaphore, etc.)
ensures that a process will not access a shared resource, which is currently in use by another process.
The synchronisation technique is only interested in avoiding conflicts that may arise due to the concur-
n
rent access of the shared resources and not at all bothered about the priority of the process which tries to
access the shared resource. In fact, the priority based preemption and lock based synchronisation are the
:he two contradicting OS primitives. Priority inversion is better explained with the following scenario:
on Let Process A, Process B and Process C be three processes with priorities High, Medium and Low re-
r. spectively. Process A and Process C share a variable 'X' and the access to this variable is synchronised

j
 Introduction to Embedded Systems

I I
I I Waiting
I I
I I Running
I I
I
I
: .g
I i:i:i I 8g
I ·,._ "' I ·:::
X
"
""
"<.>"'
I "" I ~
:,
.!1
I i>:: 2
. "' I 4) ~
l~.l:l I~.§
I~~. I ·-"'
I~
I ~ o.
e I Jl 8
I <U
l 8 'g I ~ ~
0"
I ,.. "
""
I g g
I "'~
:; I ~ti:
I "' I ]
I I "
I I
I
Process A
(High Priority)
· Process B
(Med P1iofity)
, Process C
(Low Priority)

through a mutual exclusion mechanism like Bina,y Semaphore S. Imagine a situation where Process C
is ready and is pickeq_ up for execution by the scheduler and 'Process C' tries to access the shared vari-
able 'X'. 'Process C' acquires the 'Semaphore S' to indicate the other processes that it is accessing the
shared variable 'X'. Immediately after 'Process C' acquires the 'Semaphore S', 'Process B' enters the
'Ready' state. Since 'Process B' is of higher priority compared to 'Process C', 'Process C' is preempted
and 'Process B' starts executing. Now imagine 'Process A' enters the 'Ready' state at this stage. Since
'Process A' is of higher priority than 'Process B', 'Process B' is preempted and 'Process A' is scheduled
for ex~cution. 'Process A' involves accessing of shared variable 'X' which is currently being accessed
by 'Process C'. Since 'Process C' acquired the semaphore for signalling the access of the shared variable
'X', 'Process A' will not be able to access it. Thus 'Process A' is put into blocked state (This condition
is called Pending on resource). Now 'Process B' gets the CPU and it continues its execution until it
relinquishes the CPU voluntarily or enters a wait state or preempted by another high priority task. The
highest priority process 'Process A' has to wait till 'Process C' gets a chance to execute and release the
semaphore. This produces unwanted delay in the execution of the high priority task which is supposed
to be executed immediately when it was 'Ready' .
. Priority inversion may be sporadic in.nature but can lead to potential damages as a result ~f missing
' critlcal deadlines. Literally speaking, priority inversion 'inverts' the priority of a high priority\task with
that of a low priority task. Proper workaround mechanism should be adopted for handling th(\priority
inversion problem. The commonly adopted priority inversion workarounds are: ·
Priority Inheritance: A low-priority task that is currently accessing (by holding the lock) a shared
resource requested by a high-priority task temporarily 'inherits' the priority of that high-priority task,
{rom the moment the high-priority task raises the request. Boosting the priority of the low priority task
to that of the priority of the task which requested the shared resource holding by the low priority task
eliminates the preemption of the low priority task by other tasks whose priority are below that of the
task requested the shared resource and thereby reduces the delay in waiting to get the resource requested
by the high priority task. The priority of the low priority task which is temporarily boosted to high is
 Real-Time Operating System (RTOS) based Embedded System Design

brought to the original value when it releases the shared resource. Implementation of Priority inheri-
tance workaround in the priority inversion problem discussed for Process A, Process B and Process C
example will change the execution sequence as shown in Fig. 10.31.

!Ill! Waiting
Running

Process A
(High Priorityl
ProcessB
(Med Priority)
Process C
(Low Priority)

------------------Time-------------------+

Priority inheritance is only a work around and it will not eliminate the delay in waiting the high prior-
ity task to get the resource from the low priority task. The only thing is that it helps the low priority task
to continue its execution and release the shared resource as soon as possible. The moment, at which the
low priority task releases the shared resource, the high priority task kicks the low priority task out and
grabs the CPU -A true form of selfishness©. Priority inheritan_ce handles priority inversion at the cost
of run-time overhead at scheduler. It imposes the overhead of checking the priorities of all tasks which
tries to access shared resources and adjust the priorities dynamically.
Priority Ceiling: In 'Priority Ceiling', a priority is associated with each shared resource. The priority
associated to each resource is the priority of the highest priority task which uses this shared resource.
This priority level is called 'ceiling priority'. Whenever a task accesses a shared resource, the scheduler
elevates the priority of the task to that of the ceiling priority of the resource. If the task which accesses
the shared resource is a low priority task, its priority is temporarily boosted to the priority of the high-
est priority task to which the resource is also shared. This eliminates the pre-emption of the task by
other medium priority tasks leading to priority inversion. The priority of the task is brought back to the
original level once the task completes the accessing of the shared resource. 'Priority Ceiling' brings
the added advantage of sharing resources without the need for synchronisation techniques like locks.
Since the priority of the task accessing a shared resource is boosted to the highest priority of the task
among which the resource is shared, the concurrent access of shared resource is automatically h_andled .
. Another advantage of 'Priority Ceiling' technique is that all the overheads are at compile time instead of
 Introduction to Embedded Systems

run-time. Implementation of 'priority ceiling' workaround in the priority inversion problem discussed
for Process A, Process B and Process C example will change the execution sequence as shown in
Fig. 10.32.
I
I
I'
I I I re
I I I I Waiting
I II I Ill
I I I
I
I I I I Running ac
I
I
.,1
~I] i::
I
I
at
I ;,51 ".£ 1§ Ce
I ~I.§ 8 1·.::""
l £ i:,::
]
I '5 ~
I g ~
I
I
g ·E
>< ;;
Bi
I "' .,
1 _g g ;; I ~ ,E .,
l "' .,
" SC
1§.o ~ I ~ --c, I·!~
I i! 2
G) · - !l)
-51 Jl'.g I.£"' al
I< '"8 "' I " .,
~,-a~ ti!
1Su m
I "' ...
"'"'
I ., .&: 5 I S "' I 8 ~
I " 8 "'
] I 8 .:::? 1 lri 8 w
I i:>.. <1 <~ I "'
"' o ...
I ~ I ~ ~ I 8 i:i..
I 80 I .o3 g 1-,
I 8 th
&:: Ip::,:,... Ii:>..
I
I I I
I
I
I
th
Process A I
(High Priority) I Ji
I
Process B m
(Med Priority)
er
Process C
(Low Priority)

Time

lhe biggest drawback of 'Priority Ceiling' is that it may produce hidden priority inversion. With 'Pri-
ority Ceiling' technique, the priority of a task is always elevated no matter another task wants the shared
resources. This unnecessary priority elevation always boosts the priority of a low priority task to that of
the highest priority tasks among which the resource is shared and other tasks with priorities higher than
that of the low priority task is not allowed to preempt the low priority task when it is accessing a shared tl:
resource. This always gives the low priority task the luxury of running at high priority when accessing tl:
shared resources©. cl
a1
10.8.2 Task Synchronisation Techniques te
cl
So far we discussed about the various task/process synchronisation issues encountered in multitasking
1T
systems due to concurrent resource access. Now let's have a discussion on the various techniques· used
(c
for synchronisation in concurrent access in inultitaskitlg. Process/Task synchronisation is essential for
d
1. Avoiding conflicts in resource acces~ (racing, deadlock, starvation, livelock, etc.) in a multitasking
g
environment.
2. Ensuring proper sequence of operation across processes. The producer consumer problem is a
typical example for processes requiring proper sequence of operation. In producer consumer prob-
lem, accessing the shared buffer by different proce~s is not the issue, the issue is the writing
'
process should write to the shared buffer only if the buffer is not full and the consumer thread
t
 Real-Time Operating System (RTOS) based Embedded System Design

should not read from the_buffer if it is empty. Hence proper synchronisation should be provided to
implement this sequence of operations.
3. Communicating between processes.
The code memory area which holds the program instructions (piece e:,f code) for accessing a shared
resource (like shared memory, shared variables, etc.) is known as 'critical section'. In order to synchro-
nise.the access to shared resources, the access to the critical section should be exclusive. The exclusive
access to critical section of code is provided through mutual exclusion mechanism,. Let us have a look
at how mutual exclusion is important in concurrent access. Consider two processes Process A and Pro-
cess B running on a multitasking system. Process A is currently running and it enters its critical section.
Before Process A completes its operation in the critical section, the scheduler preempts Process A and
schedules P_rocess B for execution (Process Bis of higher priority compared to Process A). Process B
also contains the access to the critical section which is already in use by Process A. If Process B contin-
ues its execution and enters the critical section which is already in use by Process A, a racing condition
will be resulted. A mutual exclusion policy enforces mutually exclusive access of critical sections.
Mutual exclusions can be enforced in different ways. Mutual exclusion blocks a process. Based on
the behaviour of the blocked process, mutual exclusion methods can be classified into two categories. In
the following section we will discuss them in detail.
10.8.2.1 Mutual Exclusion through Busy Waiting/Spin Lock 'Busy waiting' is the simplest
method for enforcing mutual exclusion. The following code snippet illustrates how 'Busy waiting'
enforces mutual exclusion.

The 'Busy waiting' technique uses a lock variable for implementing mutual exclusion. Each process/
thread checks this lock variable before entering the critical section. The lock is set to 'J' by a process/
thread if the process/thread is already in its critical section; otherwise the lock is set to 'O'. The major
challenge in implementing the lock variable based synchronisation is the non-availability .of 9- single
atomic instructiont which combines the reading, comparing and setting of the lock variable. Most of-
ten the three different operations related to the locks, viz. the operation of Reading the lock variable,
I

checking its present value and setting it are achieved with multiple low level instructions. The lowilevel
implementation of these operations are dependent on the underlying processor instruction set and the
(cross) compiler in use. The low level implementation of the 'Busy waiting' code snippet, which we
discussed earlier, under Windows XP operating system running on an Intel Centrino Duo processor is
given below. The code snippet is compiled with Micrnsoft Visual Studio 6.0 compiler.
,--- D: \Exarnples\counter ..cpp -------------- ---------------- . ---- --
~~= . #include <stdio.b>
'.2: #include <windows.h>

t Atomic Instruction: Instruction whose execution is uninterruptible.

 Introduction to Embedded Systems

run-time. Implementation of 'priority ceiling' workaround in the priority inversion problem discussed
for Process A, Process B and Process C example will change the execution sequence as shown in
Fig. 10.32.

Waiting

Running

Process A
(High Priority)
Process B
(Med Priority)

ProcessC
(Low Priority)

The biggt::st drawback of 'Priority Ceiling' is that it may produce hidden priority inversion. With 'Pri-
ority Ceiling' technique, the priority of a task is always elevated no matter another task wants the shared
resources. This unnecessary priority elevation always boosts the priority of a low priority task to that of
the highest priority tasks among which the resource is shared and other tasks with priorities higher than
that of the low priorityJask is not allowed to preempt the low priority task when it is accessing a shared
resource. This always gives the low priority task the luxury of running at high priority when accessing
shared resources©.

10.8.2. Task Synchronisation Techniques

So far we discussed about the various task/process synchronisation issues encountered in multitasking
systems due to concurrent resource access. Now let's have a discussion on the various techniques· used
for synchronisation in concurrent access in multitaski:vg. Process/Task synchronisation is essential for
1. Avoiding conflicts in resource access (racing, deadlock, starvation, livelock, etc.) in a multitasking
environment.
2. Ensuring proper sequence of operation across processes. The producer consumer problem is a
typical example for processes requiring proper sequence of operation. In producer consumer prob-
lem, accessing the· shared buffer by different proce's.s~s is not the issue, the issue is the writing·
process should write to the shared buffer only if the buffer is not full and the consumer thread
 Real-Time Operating System (RTOS) based Embedded System Design

should not read from the, buffer if it is empty. Hence proper synchronisation should be provided to
implement this sequence of operations.
3. Communicating between processes.
The code memory area which holds the program instructions (piece of code) for accessing a shared
resource (like shared memory, shared variables, etc.) is known as 'critical section'. In order to synchro-
nise the access to shared resources, the access to the critical section should be exclusive. The exclusive
access to criti(?al section of code is provided through mutual exclusion mechanism. Let us have a look
at how mutual exclusion is important in concurrent access. Consider two processes Process A and Pro-
cess B running on a multitasking system. Process A is currently running and it enters its critical section.
Before Process A completes its operation in the critical section, the scheduler preempts Process A and
schedules Process B for execution (Process B is of higher priority compared to Process A). Process B
also contains the access to the critical section which is already in use by Process A. If Process B contin-
ues its execution and enters the critical section which is already in use by Process A, a racing condition
will be resulted. A mutual exclusion policy enforces mutually exclusive access of critical sections.
Mutual exclusions can be enforced in different ways. Mutual exclusion blocks a process. Based on
the behaviour of the blocked process, mutual exclusion methods can be classified into two categories. In
the following section we will discuss them in detail.
I 0.8.2.1 Mutual Exclusion through Busy Waiting/Spin Lock 'Busy waiting' is the simplest
method for enforcing mutual exclusion. The following code snippet illustrates how 'Busy waiting'
enforces mutual exclusion.
~'n't ;~tlfreadlmain'.:fhre'actiicbt0Et{
.:,~<;,,:·.,.. ,~, :· "f•:•,:<<:;:·,: ·'~·: ··\: •· ··:_ •:·.: ·:;V:\;. ><.... ·J'.(/,.,..!;>'••~:,'.f":_·::·1:
Gh1tb'a'¼:'i"declar . .
;i.H:~:\l~~ "'"-~; ..,;, , '
ad

,,. ' , '',. ,. ,.; .., ..

fl~.H
de•:dea
'.·•. j ' -.-.,._,_._. :

The 'Busy waiting' technique uses a lock variable for implementing mutual exclusion. Each process/
thread checks this lock variable before entering the critical section. The lock is set to 'J' by a process/
thread if the process/thread is already in its critical section; otherwise the lock is set to 'O'. The major
challenge in implementing the lock variable based synchronisation is the non-availability of~ single
atomic instructiont which combines the reading, comparing and setting of the lock .variable. Most of-
ten the three different operations related to the locks, viz. the operation of Reading the lock variiable,
checking its present value and setting it are achieved with multiple low level instructions. The low/level
implementation of these operations are dependent on the underlying processor instruction set and the
(cross) compiler in use. The low level implementation of the 'Busy waiting' code snippet, which we
discussed earlier, under Windows XP operating syst~m running on an Intel Centrino Duo processor is
given below. The code snippet is compiled with Micrnsoft Visual Studio 6.0 compiler.
I

D:\Exai:nplE:!s\counter.cpp
·,·1: .Hncflude <$tdio.h>· ..
2· .. #'include <windows ,fr> f
!

t Atomic Instmction: Instruction whose execution is uninterruptible.

 Introduction to Embedded Systems

3:
4: int main()
5: {
//Code memory Opcode Operand
00401010' push ebp·
004010.11 mov; ebp,·esp •
00401..00 $).lb .esp, 44h
00~Ql.QXfi pu~h .;.;,.,,.:,. el'.lJt .
00,401..0:17
•;', ,r , ~ )
.'push-.
\ •,
,e~i:L
. 00401018 : edi ::
'604'oioie., ....
·o,b~t1b:i"6.t:c: 1

00401028 mov . byte pti:: [ebp:-41 ,6:.:.~ . . · , '' ,;::•. ;.1 .

·lI ~i~:I~~:;~~r~t"off{]~ilf;it)l~f1
Ffi!~tl~fft;/:, .
00401034 c;mp eax, i. · ··. :,',
00401037 jn_~ maini2Bh '.(00461:0:3b)
00401039 jritp .· · , · ~f~+.,tcti;;·rqoio'i~){Y . G
12: bFlag=TRUE; )/Lock is ·available.,:Acquir~
0040103B . mov ·· byte ptp 1 [~bp-:4g.f
f
The assembly language instructions reveals that the two high level instructions (whi!e(bFlag==false); (
and bFlag=true;), corresponding to the operation of reading the lock variable, checking its present
value and setting it is implemented in the processor level using six low level instructions. Imagine a
situation where 'Process l' read the lock variable and tested it and found that the lock is available and
it is about to set the lock for acquiring the critical section (Fig. 10.33). But just before 'Process 1' sets (
the lock variable, 'Process 2' preempts 'Process 1' and staiis executing. 'Process 2' contains a critical t
section code and it tests the lock variable for its availability. Since 'Process 1' was unable to set the lock
variable, its state is still 'O' and 'Process 2' sets it and acquires the critical section. Now the scheduler
preempts 'Process 2' and schedules 'Process l' before 'Process 2' leaves the critical section. Remember,
'Process 1' was preempted at a point just before setting the lock variable ('Process l' has already tested
the lock variable just before it is preempted and found that the lock is available). Now 'Process 1' sets
the lock variable and enters the critical section©. It violates the muhial exclusion policy and may pro-
duce unpredicted results.
The above issue can be effectively tackled by combining the actions of reading the lock variable,
testing its state and setting the lock into a single step. This can be achieved with the combined hardware
and software support. Most of the processors support a single instruction 'Test and Set Lock (TSL)' for
testing and setting the lock variable. The 'Test and Set Lock (TSL)' instruction call copies the value of
the lock variable and sets it to a nonzero value. It should be noted that the implementation and usage of
 Real-Time Operating System (RTOS) based Embedded System Design

'Test and Set Lock (TSL)' instruction is processor architecture dependent. The Intel 486 and the above
family of processors support the 'Test and Set Lock (TSL)' instruction with a special instruction CMPX-
CHG-Compare and Exchange. The usage of CMPXCHG instruction is given below.
CMEXCHG dest,src
This instruction compares the Accumulator (EAX register) with '<lest'.. If the Accumulator and '<lest'
contents are equal, '<lest' is loaded with 'src'. If not, the Accumulator is loaded with '<lest'. Executing
this instruction changes the six status bits of the Program Control and Status register EFLAGS. The
destination ('<lest') can be a register or a memory location. The source ('src') is always a register. From
a programmer's perspective the operation of CMPXCHG instruction can be viewed as:
if (accumulator destination)

ZF =l; //Set the Zero Flag of EFLAGS Register

destination =source;\
}

ZF = of EFLAGS Register
accumulator r

-; .... --,·.
 Introduction to Embedded Systems

The process/thread checks the lock variable to see whether its state is 'O' and sets its state to '1' if its
state is 'O', for acquiring the lock. To implement this at the 486 processor level, load the accumulator
with 'O' and a general purpose register with' l' and compare the memory location holding the lock vari-
able with accumulator using CMPXCHG instruction. This instruction makes the accessing, testing and ~
modification of the lock variable a single atomic instruction. How the CMPXCHG instruction support ·
provided by the Intel® family of processors (486 and above) is made available to processes/threads is
OS kernel implementation dependent. Let us see how this feature is implemented by Windows Operat-
ing systems. Windows CE/Windows XP kernels support the compare and exchange hardware feature
provided by Intel® family of processors, through theAPI call InterlockedCompareExchange (LPLONG
Destination, LONG Exchange, LONG Comperand). The variable Destination is the long pointer to the
destination variable. The Destination variable should be of type 'long'. The variable Exchange rep-
resents the exchange value. The value of Destination variable is replaced with the value of Exchange
variable. The variable Comperand specifies the value which needs to be compared with the value of
Destination variable. The function returns the initial value of the variable 'Destination'. The following
code snippet illustrates the usage of this API call for thread/process synchronisation.
/ /Inside parent thread/ ,:main ".thfead .corresponding to· a:-· process
long bFlag; / /Globa} (i~c;;laration pf Jopk Variable.
bFlag=O; JI Initialis~ '.fl)tloJ'.:k:(t·~: inai:c'a~e. ,i's ayaHable. · · ..
I I ................................. ,.. .............. :+,<:·-- ,.~ .;) "_. ..,);·~. :. :· ,... ' ... :, . . m . . ••· . . . . . . . . ••-- :· ..................... : ••

//Inside the child threads/ threads of a process

/ /Check the loc.k, 1vaile-l:;i1ify & aq~ul~~ the_ ],ock if available.
while (InterlockedCompar:~Exchange (&bF.lag, l,_ Q)' l};

//Rest of the source code dealing with shared resource access

The InterlockedCompareExchange function is implemented as 'Compiler intrinsic function'. The
'code for Compiler intrinsic functions' are inserted inline while compiling the code. This avoids the
function call overhead and makes use of the built-in knowledge of the optimisation technique for intrin-
sic functions. The compiler can be instructed to use the intrinsic implementation for a function using
the compiler directive #pragma intrinsic (intrinsic-fimction-name). A sample implementation of the
InterlockedCompareExchange interlocked intrinsic function for Windows XP OS is given below.
#include "stdafx.hu
#include <intrin.h>
#include <windows.h>
long bFlag; //Global declaration of lock Variable.
//Declare InterlockedCompareExchange as intrinsic function
#pragma intrinsic InterlockedCompareExchange}
void child thread(void)
{
//Inside the child thread of a process
//Check the lock for availability & acquire the lock if available.
//The lock can be set by any other threads
while (_InterlockedCompareExchange (&bFlag, 1, 0) == l);
//Rest of the source code dealing with shared resource access
// .................................................... ···.•··· ····.·· .,
return;
/
 Real-Time Operating System (RTOS) based Embedded System Design

. I I .................................................................. .
int _ tmain {int argc, TCHAR* argv ['f)
{
I= . / /Inside ipar12nt' thread/ main thread corresponding to a process
DWORD thrl':ad_.id;
_ :/.f°iifif!~,J~~rj_?l~, to the chit~ thr~ad
'. ,;HANDLE t[lh,read; ::.Lt, t. :·: 1~•~:::
is available;
'
T

f ?if (NULL== tTbrea:ct-i : ; j : ..

Ii){i:1£iid .,ir~id .cfeatJ,on ,<ekted,; .'

< priritf' .( 1\Creafion of Child thread failed, Error Code =
. %ct''., GetLastErro.d) ) ; ,
:\.;.;'\,J\<,,·' ,~ ',',:_;,~:;:,;;'"".,',,i\;,;",,'.,,,f t
I'

,; return ...:l;
?t:. •.,i . ,.. ,: .'.,,,'Ti ,, ..;·,
, 4./Wai ·f''foi th~:: cd-mple'tibr(''<;)r :tile
child ·.thiead;
'.'.-: ;' . . . .· ' ' · · ·.,.;..

f_WaitFors{ngl~Q~jlct{t.Th~~act~'INFINITEf;
fir.eturn O{ .: : ·'t;.' · .
:'}

Note: Visual Studio 2005 or a later version of the compiler, which supports interlocked intrinsic
e functions, is required for compiling this application. The assembly code generated for the intrinsic
e
interlocked function while (_JnterlockedCompareExchange (&bFlag, 1, 0) 1); when compilea'us-
l-
ing Visual Studio 2005 compiler, on Windows XP platform with Service Pack 2 running on an Intel®
Centrino® Duo processor is given below. It clearly depicts the usage of the cmpxchg instruction
g
e //Inside the child threads/ threads of a process
//Check the lock for availability & acquire the lock if available.
//The lock can be set by any other threads
while InterlockedCompareExchange (&bFlag, 1, 0) == 1);
004113DE -mov ecx,1
004113E3_ mov edx,offset bFlag (417178h)
004113E8 ·xor eax,eax
004113EA lock cmpxchg d.word ptr [edx],ecx
004113EE cmp eax,l
004113.Fl jne child- thread+35h ( 4113F5h)
004113F3 jmp child- thread+lEh {4113DEh)
//Rest of the source code dealing with shared resource access
I I .......................................................... .
The Intel 486 and above family 6f processors provide hardware level support for atomic execution of
increment and decrement operations also. The XADD low level instruction implements atomic execu-
tion of increment and decrement operations. Windows CE/XP kernel makes these features available to
the users through a set of Interlocked function API calls. The API call Interlockedlncrement (LPLONG
 Introduction to Embedded Systems

lpAddend) increments the value of the variable pointed by lpAddend and the API lnterlockedDecrement
(LPLONG lpAddend) decrements the value of the variable pointed by lpAddend.
The lock based mutual exclusion implementation always checks the state of a look and waits till the
lock is available. This keeps the processes/threads always busy and forces the processes/threads to wait
for the availability of the lock for proceeding further. Hence this synchronisation mechanism is popu-
larly known as 'Busy waiting'. The 'Busy waiting' technique can also be visualised as a lock around
which the process/thread spins, checking.for its availability. Spin locks are useful in handling scenarios
where the processes/threads are likely to be blocked for a shorter period of time on waiting the lock, as
they avoid OS overheads on context saving and process re:-scheduling. Another drawback of Spin lock
based synchronisation is that if the lock is being held for a long time by a process and if it is preempted
by the OS, the other threads waiting for this lock rriay have to spin a longer time for getting it. The 'Busy
waiting' mechanism keeps the process/threads· always active, performing a task which is not useful and
leads to the wastage of processor time and high power consumption.
The interlocked operations are the most efficient synchronisation primitives when compared to the
classic lock based synchronisation mechanism. Interlocked function based synchronisation technique
brings the following value adds.
• The interlocked operation is free from waiting. Unlike the mutex, semaphore and critical section
synchronisation objects which may require waiting on the object, if they are not available at the
time of request, the interlocked function simply performs the operation and returns immediately.
This avoids the blocking of the thread which calls the interlocked function.
• The interlock~d function call is directly converted to a processor specific instruction and there is
no user ·mode to kernel mode transition as in the case of mutex, semaphore and critical section
objects. This avoids the user mode to kernel mode transition delay and thereby increases the over-
all performance.
The types of interlocked operations supporrecrby an OS are underlying processor hardware depen-
dent and so they are limited in functionality. Normally the bit manipulation (Boolean) operations are not
supported by interlocked functions. Also the interlocked operations are limited to integer or pointer vari-
ables only, This limits the possibility of extending the interlocked functions to variables of other types.
Under wirtdows operating systems, each process has its own virtual address space and so the interlocked
functions can only be used for synchronisi:ng the access to a variable that is shared by multiple threads of
a process (Multiple threads .of a process share the same address. space) (Intra Process Synchronisation).
The interlocked functions can be extended for synchronising the access of the variables shared across
multiple processes if the variable is kept in shared memory.
10.8.2.2 Mutual Exclusion through Sleep & Wakeup The 'Busy waiting' mutual exclusion en-
forcement· mechanism used by processes makes the CPU always busy by checking the lock to see
whether they can proceed. This results in the wastage of CPU time and leads to high power consump-
tion. This is not affordable in embedded systems powered on battery, since it affects the battery backup
time of the device. An alternative to 'busy waiting' is the 'Sleep & Wakeup' mechanism. When a process
is not allowed to access the critical section, which is currently being locked by another process, the
process undergoes 'Sleep' and enters the 'blocked' state. The process which is blocked on waiting for
access to the critical section is awakened by the process which currently owns the critical section. The
process which owns the critical section sends a wakeup message to the process, which is sleeping as a
result of waiting for the access to the critical section, when the process leaves the critical section. The
'Sleep & Wakeup' policy for mutual exclusion can be implemented in different ways. Implementation of
 Real-Time Operating System (RTOS) based Embedded System Design

t this policy is OS kernel dependent. The following section describes the important techniques for 'Sleep
& Wakeup' policy implementation for mutual exclusion by Windows XP/CE OS kernels.

t Semaphore Semaphore is a sleep and wakeup based mutual exclusion implementation for shared
resource access. Semaphore is a system resource and the process which wants to access the shared
resource can first acquire this system object to indicate the other processes which wants the shared
resource that the shared resource is currently acquired by it. The resources which are shared among a
process can be either for exclusive use by a process or for using by a number of processes at a time. The
display device of an embedded system is a typical example for the shared resource which needs exclu-
sive access by a process. The Hard disk (secondary storage) of a system is a typical example for sharing
the resource among a limited number of multiple processes. Various processes can access the different
sectors of the hard-disk concurrently. Based on the implementation of the sharing limitation of the
shared resource, semaphores are classified into two; namely 'Binary Semaphore' and 'Counting Sema-
phore'. The binary semaphore provides exclusive access to shared resource by allocating the resource to
a single process at a time and not allowing the other processes to access it when it is being owned by a
process. The implementation of binary semaphore is OS kernel dependent. Under certain OS kernel it is
referred as mutex. Unlike a binary semaphore, the 'Counting Semaphore' limits the access of resources
· by a fixed number of processes/threads. 'Counting Semaphore' maintains a count between zero and a

Semaphore object unavailable. Sleep till

Semaphore object is available
Room(Key) unavailable.
+ - - - Wait till it is available 7
Is Semaphore object
available?

- - - Is Key Available? - -....

@
-~~\1/j
'1~'
~
<.f,,(d

Vacating the Room. Return the Key. Notify

the availability to other users booked the Room
Leaving critical section . Release the Semaphore object.
Wakeup the Sleeping Processes

[fig. 10.34) TlieConceptof Counting~emaphore

 Introduction to Embedded Systems

value. It limits the usage of the resource to the maximum value of the count supported by it. The state of
the counting semaphore object is set to 'signalled' when the count of the object is greater than zero. The
count associated with a 'Semaphore object' is decremented by one when a process/thread acquires it and
the count is incremented by one when a process/thread releases the 'Semaphore object'. The state of the
'Semaphore object' is set to non-signalled when the semaphore is acquired by the maximum number of
processes/threads that the semaphore can support (i.e. when the count associated with the 'Semaphore
object' becomes zero). A real world example for the counting semaphore concept is the dormitory sys-
tem for accommodation (Fig. 10.34). A dormitory contains a fixed number of beds (say 5) and at any
point of time it can be shared by the maximum number of users supported by the dormitory. If a person
wants to avail the dormitory facility, he/she can contact the dormitory caretaker for checking the avail-
ability. If beds are available in the dorm the caretaker will hand over the keys to the user. If beds are not
available currently, the user can register his/her name to get notifications when a slot is available. Those
who are availing the dormitory shares the dorm facilities like TV, telephone, toilet, etc. Wben a donn
user vacates, he/she gives the keys back to the caretaker. The caretaker informs the users, who booked
in advance, about the dorm availability.
The creation and usage of' counting semaphore object' is OS kernel dependent. Let us have a look at
how we can implement semaphore based synchronisation for the 'Racing' problem we discussed in the
beginning, under the Windows kernel. The following code snippet explains the same.

:I~:~;~:J~;~:::~!)? -'.- . ;,:;::t1;ir:;;:?t;:{{fI'

J:,ci~fine.,~ SEMAPH()RE :COU.Na:'::l,t _~:;Lthe, ~ ..

,;;;~;;,;;;;~,;:~~f ; . ·;c 'iiiJ~t'+ ,,?fvfJ!~f{ti

// cou~ter · ·is . I11<" · ti; ~\,f
1

two th:reacls ::ei-6~~ ATarid·-P'i8

<' ,,, '.';;
'.\ ';_,,"'~'., ...- ' -.'..f/·~
,•. J•;-J',,,.;

char Buffer [1@ · ;,,,.'.•'{lf~,?~,:4,s;:6,·1,;:

sh6rt int coun'tet:;f:::,;·~b;/:r( : ', .•' ·
//Define the handle to Semaphore ob ⇒ ect
HANDLE hSemaphore;
I/*************.********************************",..*********************
// Child Thread 1
void Process A (void) {
inti;
for (i =0; i<5; it+)

if (Buffer (i] > 0)

{
//Wait for the signaling of Sem~phore object
Wai tForSingleObj.ect (hSeml3.phore, INFINITE) ; ·
-//Semaphore is acquired
counter++;
printf("Proce~s A: Counter= %d\n",counter);
I /Release the Semaphore Obj_ect

if ( ! ReleaseSemaphore (
hSemaphore, // handle to semaphore
 Real-Time Operating..System (RTOS) based Embedded System Design

1, // increase count by one

NULL)) // not. interes.ted in previous count

/ /Sema,phore Release failed. Print Error code &

return.
priritf (''Release Semiiphore _Fatleq with ·Eri'or>tode:
%d\n';;; GetLastErroi() ) ;
•✓ ; , ,.
- , - . ,·· .

Child· Thr.ead 2
Void
-<:.
Process - B (void)
, '
int j;
\~:,for (j =Sr j<lO; .j++)
t': ,
'if . {Buffer [j] > 0)
>{
//Wait for the signalling' of S~rrfaph6re.. obj'f=ct
. WaitForSingleObj~ct (hSemaphore, INFI.NITE);
,; V ' ' ,•,• ; ,.,

/Ysemaphore is acquired
_counter++; . , _
p,riritf ("Process B ;_tsmnter %d\n''', counter) ;
/ /Release ~emirpllo~e
_if ( ! ReleaseSemaph'ore (
· hSem6!.phore, I I han_dle to semaphore
1~ // incre~se couht by one
NULL) // not interested in previous count

//Semaphore Release failed. Print-Error code &

//return.
printf(ftRelease Semaphore Failed Error Code: %d\n",
.
GetLastError());
return;

return;

//*******************************************************************
// Main Thread
void main () {

//Define HANDLE for child threads

HANDLE child_threads[thread_count];
 Introduction to Embedded Systems

R,
DWORD thread id; ac
int,,i;
C
//Cieate ~ema~hoie object
si ·.
· hS~r:naphore = Ci'ea teSemaphore ( rn.
·NULL; II default ~ecurity attributes
£1A:X:::9E~)?~OR,£2::_COUNT,, j/. initial .. c'our1t:, Create !=ls signaled se
· ,MAK2sE~PHORK_COUNT, / / maximum count . . se
·' ,iSei!iJi.phqire}~JJ ' // :~·emapho\~ obj e·~t with name "S_ernaphore" B.
"·\~~:'.\~ .

't/i'::f({(Ngt:r/=~ ·.h'sfiua:pl16i;~) <., . fc

th

jfifi!{~~l;:~= •::::::t::;:::. :;~~::

01;,
w··
·.·Eri6± cooe, th
''return; ::· ·•· ·;':; .," Fi
l. th
· //Crea'tE~ .Child thread :1 C<
chi·.ld_ threads [ o'J =' . · CreateThi'e~ci'(NULii
',.hi
Ji '.f, . >,
> •.:•'./," "'. '.•. . , • •'--,,:cf-:,:<:.:••.
1 ;• :.•
.
.'i:', n:
(LP;:r'HRE'l\I) S1'AR1' J~.G;IJ'.J'Il'{E}J'.roc.e;:;s;:A.,...
'i·:·'"'" ,, >,
(LPVOIDj b;Q /&th;::eact·\fct),; ..· •, .' '. - .
'<,• ,,~• "e -

. I/C:I:eate <::hild thread 2 1

. cPi'i1 d.:_tbre~d·~ [ i l ~ ·•· ·· . Cr~~ ~,~·1~?;~~:g::r#u1'~,'·bit1h,:;\t, "

(LPTHREAD START ROLfI'lNE)Pr~>'cess'<B,· .
;,<," ...

· !l;beck the success .of cre~tpi:t

for. (i=O; i <thre'ad~-.·.count;'.
1

if+T ,.·.
t)foiflit
11
1:ar1;fd~J , .. -
··., ,,;; ,.

if(NULL==child_threads[i])
{
//Child thread creation failed.
printf ("Child thread Creation failed with Error Code: %d 11 ,
GetLastError ());
return;

}
// Wait for the termination of child threads
WaitForMultipleObjects(thread_count, child_threads, TRUE,
INFINITE)·;
//Close handles of child threads
for( i=O; i < thread_count; it+
C1oseHandle(child_threads[i]);
//Close Semaphore object handle
CloseHandle(hSemaphore);
return;

Please refer lO the Online Learning Centre for details on the various Win32 APis used in the program
for counting semaphore creation, acquiring, signalling, and releasing. The VxWorks and MicroC/0S-II (
 Real-Time Operating System (RTOS) based Embedded System Design

Real-Time kernels also implements the Counting semaphore based task synchronisation/shared resource
access. We will discuss them in detail in a later chapter.
Counting Semaphores are similar to Binary Semaphores in operation. The only difference between
Counting Semaphore and Binary Semaphore is that Binary Semaphore can only be used for exclu-
sive access, whereas Counting Semaphores can be used for both exclusive access (by restricting the
maximum count value associated with the semaphore object to one ( 1) at the time of creation of the
semaphore object) and limited access (by restricting the maximum count value associated with the
semaphore object to the limited number at the time of creation of the semaphore object).
Binary Semaphore (Mutex) Binary Semaphore (Mutex) is a synchronisation object provided by OS
for pro_cess/thread synchronisation. Any process/thread can create a 'mutex object' and other processes/
threads of the system can use this 'mutex object' for synchronising the access to critical se_ctions. Only
one process/thread can own the 'mutex object' at a time. The state of a mutex object is set to signalled
when it is not owned by any process/thread, and set to non-signalled when it is owned by any process/
thread. A real world example for the mutex concept is the hotel accommodation system (lodging system)
Fig. 10.35. The rooms in a hotel are shared for the public. Any user who pays and follows the norms of
the hotel can avail the rooms for accommodation. A person wants to avail the hotel room facility can
contact the hotel reception for checking the room availability (see Fig. 10.35). If room is available the
receptionist will handover the room key to the user. If room is not available currently, the user can book

Mutex object unavailable. Sleep till

·· Mutex object is available
Room (Key) unavailable.
Book & Wait till it is available

Is Mutex object available?

Leaving critical section. Release the Mutex object.

Wakeup the Sleeping Processes
Vacating the R.oom. Return the Key. Notify
the availability to other users who booked the Room

QFig.10;35) The Concept ofBinarySemaphore.(¥utex)

 Introduction to Embedded Systems

the room to get notifications when a room is available. When a person gets a room he/she is granted the
exclusive access to the room facilities like TV, telephone, toilet, etc. When a user vacates the room, he/
she gives the keys back to the receptionist. The receptionist informs the users, who booked in advance,
about the room's availability.
Let's see how we can implement mutual exclusion with mutex object in the 'Racing' problem ex-
ample given under the section 'Racing', under Windows kernel.
· , "·:< _di_o~h>
'dows.h>.
4
c0u~t 2:, · : . _ _ :, L/!'!?i:_9J:p~ilcl::H'h7eadt'l. _
* **·* **_:/,; *.*.** ** ** *'"'*** ** * **·*·**·*** *·**·*.**·*** * ** * ** ** * * ** ** * *
i'.}t'.~int~~~f::~~i~ah1e··'ihct.i~i{tel'
0
a: :a~ray sh~red. i.~t- byti

_:_!:;.'i,.~h;:ef
',tJii'.,.~n·-·.·;,.·_e
1 ·-e~~i~;.~~dir
~_:.,_;,:_·.:h),~i ~.;n\d~.:l·_,_
9
' . . ' • . .
~ (ai•Mut~x Ob;j~ct:\-: .' .
i/iHAND.t'E~fhMui!t:ix;\' < • .. . , , ,. ,;, ·- . ·-
~-i_,_rf~o~:r~:.~.!i::c_ ·!it1tti~i1,?;•:ti: •,rt~.>}.\•,•~~ Ci7·WMt;,', '.,.,, ',,, ~,; ~
,_._, ·,.I =:Q/ i<'.${ it,f)._·
/~ -

,if· .(Buffer[i]' > 0)

{ ' <

//wait '.fo'r ,s1tjha1ling 'of 1th~- ~utex ''obj'ect;

~ '" .··. ''. ,. _ fr!:,·- ..t { ... ·. •"-':,~,"·0--~ ·•. ·",") ",
'''°."':'."-'·.·,'" .,_.·. --·,, ... , . , '•

Wai tFqi!::~.i.pgJ~Ol:);ject(hMute;x, INFJNITE) ;

I !Mut~i i( a2q~f~~d< . " , .
counter+i-;Yi
printf("P;dbess A counter
//Release the Mutex Object

if (!ReleaseMute}(;(hMutex)) // handle to Mutex Object

{
//Mutex object Releasing failed. Print Error code & return.
printf("Release Mutex Failed with Error Code: %d\n",
GetLastError());
return;

return;

//******x************************************************************
// Child Thread 2
void Prcc~3s_B(void)
int j;
 Real-Time Operating System (RTOS) based Embedded System Design

for (j =5; j<lO; j++)

if (Buffer[j] > D)
{
• //Wait for •signalling of the Mutex object
Wa'itFor$ingl:eObject (hMutex, INFINITE);
. I /Mutex object is;:,acquired ' .,.:;;, •·
: cqunt~:r+:+)\ ~ ,d , / ,. •;'·::~:~">, ~, ·,,
.:,.

::prJhtf U\pr'aces;s ;1\;j AJouµter %d\n·", c0Unter) ; , ·.

-· ~J/~eleasg;,[ijdti~--D~Je9t_. ':.. ~,-: ::J:~::~ ,
. . il j !Re'l'.easeijutex1hMute:k) ).... } l;::!:·a)1dle/t
, ! i /~u";", o;l e it ,y;t~ i;,:.
p ;,i<! •;i'ririt' ·?;'{Or 'qg~
print:f ("~e,lease-:Mµtex Fp.iled>with ,trrQi?·¢ode:. %~\;n~;
G~ti:~:~,tE:tror())'; ' ·" ' ···:,),·:; '\.•;
··•.,_+. ",,.,:,•··

r~turn;

//)1aih _Thread·
v'~id.
n:ain () { .·
···.
/ /Define HANDLE .for child threads
HANDLE child threads[thread_count];
DwoRD ·th~ead id;
inti;

//Create Mutex object

hMutex = CreateMutex(
NULL, // default security attributes

I
FALSE, // Not initial ownership
"Mutex"); II Mutex object with name "Mutex"
if (NULL== hMutex)
{
I printf ("Mutex Object Creation Failed: Error Code: %d",
GetLastError ());
//Mutex Object Creation failed. Return
return;

//Create Child thread 1

child_threads[O]= '•
CreateThread(NOLL,O,
(LPTHREAD_START_ROUTINE)Process A,
(LPVOID)0,0,&thread id);

1
 Introduction to Embedded Systems

IS l
/ /Crea.te ·c::hild thread 2 (Ll
·cb;iict
) if:hn.e~cls
.-=-~v , ' '•. '-"','; \' •-[.lJ~
-• p01
the
cal
sec
thr
en1
the
cal
me
Cal
!TI
(Li
wr
COl
sm

· •ci~i3.e.Ha,na... , .. ;~'xr;?'
•~'," ,::,
re:tu:r:ri; ;;

Please refer to the Online Learning Centre for details on the various Win32 APis used in the program
for mutex creation, acquiring, signalling, and releasing. ·..
The mutual exclusion semaphore is a special implementation of the binary semaphore by certain
real-time operating systems like VxWorks and MicroC/OS-ll to prevent priority inversion problems in V
shared resource access. The mutual exclusion semaphore has an option to set the priority of a task own- i
ing it to the highest priority of the task which is being pended while attempting to acquire the semaphore
which is already in use by a low priority task. This ensures that the low priority task which is currently
holding the semaphore, when a high priority task is waiting for it, is not pre-empted by a medium prior-
ity task. This is the mechanism supported by the mutual exclusion semaphore to prevent priority inver-
sion.
VxWorks kernel also supports binary semaphores for synchronising shared resource access. We will
discuss about it in detail in a later chapter.
Critical Section Objects In Windows CE, the 'Critical Section object' is same as the 'mutex object'
except that 'Critical Section object' can only be used by the threads of a single process (Intra process).
The piece of code which needs to be made as 'Critical Section' is placed at the 'Critical Section' area
by the process. The memory area which is to be used as the 'Critical Section' is allocated by the pro-
cess. The process creates a 'Critical Section' area by creating a variable of type CRJTICAL_SECTION. I
I
The Critical Section' must be initialised before the threads of a process can use it for getting exclusive
access. The lnitializeCritica!Section(LPCRJTICAL_SECTION lpCriticalSection) API initialises the
critical section pointed by the pointer lpCriticalSection to the critical section. Once the criticaLsection
 Real-Time Operating System (RTOS) based Embedded System Design

is initialized, all threads in the process can use it. Threads can use the API call EnterCriticalSection
(LPCRJTICAL_SECTION lpCriticalSection) for getting the exclusive ownership of the critical section
pointed by the pointer lpCriticalSection. Calling the EnterCriticalSection0 API blocks the execution of
the caller thread if the critical section is already in use by other threads and the thread waits for the criti-
cal section object. Threads which are blocked by the EnterCriticalSectionQ call, waiting on a critical
section are added to a wait queue and are woken when the critical section is available to the requested
thread. The API call TryEnterCriticalSection(LPCRJTICAL_SECTION lpCriticalSection) attempts to
enter the critical section pointed by the pointer lpCriticalSection without blocking the caller thread. If
the critical section is not in use by any other thread, the cailing thread gets the ownership of the criti-
cal section. If the critical section is already in use by another thread, ·the TryEnterCriticalSection0 call
indicates it to the caller thread by a specific return value and the thread.resumes its execution. A thread
can release the exclusive ownership of a critical section by calling the API LeaveCriticalSection(LPCR-
ITICAL _SECTJON lpCriticalSection). The threads of a process can use the API DeleteCriticalSection
(LPCRJTICAL _flECTJON lpCritica/Section) to release all resources used by a critical section object
which was created by the process with the CRITICAL_SECTION variable.
Now let's have a look at the 'Racing' problem we discussed under the section 'Racing'. The racing
condition can be eliminated by using a critical section object for synchronisation. The following code
snippet illustrates the same.
:'\ftinc lude <stdio. h>
0

t#fhctude <win.dow~.h> . .·
·:il~*~\,,, *·*:** *·* ;i<t* ***~**** *t*-!; ** * ~ * *'l<tt {J·* t~ ;_*17,~-*5* t~*/**} **t/* * * * * * *
·1/do~titer is an integ~r v'ariable and 'B1./ixe~ :i>~ la:tfyt·~ array shared
, /lbet~een ·. two .tnre1ps · .. · · · ··
;;:Oh;flr ·Buff~r [10] ~= :>{i~ 2, 3" 4,5, 6, 7,·s., 9, 10};; __._
:$hart "i:fft counter.='. .O;
:i·f/Defi~e · the ciitic~i ~ection
A 1• •,", > ,1, ,• ' " ':, • • S

;.,CRIT.ICAL_ SECTION C~/ .

,:.l-l*'** * *** ** *** ****-!;** ***** ** * *·* *** **·*·* * * **.**:* ** * ** ***** ******* **** ** *
\\1/;/ Child Thread 1 ··
void Process_A (void} {
. .,int i;
for (i =0; i<5; i++)

I if (Buffer[i] > 0)
{
//Use critical sectibn object for synchronisation
EnterCriticalSection(&CS);
counter++;
LeaveCriticalSection(&CS);

printf(uProcess A: Counter %d\n",counter};

b::I I*****.************************************************·**************
j/1 I Child Thread 2
pvoid Process_B(void)
 Introduction to Embedded Systems

int j;
_for (j =5; j<l0; j++}

if.(Buffer(j] > 0)
l
.. //Use· critical se.ction object ror-synctrronisation
(&CS) ;

D~ORD id;
'• ' •, :,-• . •;•=,0-ii~n,' ••••:_?'• .,- _.,. ;:.:,t"/·.<~\•.•.'v •f. v{:,~.-?-,,._ ,> ab
//Initializ.e tritiial,s~cfl_?n. op3ect
in'i tializecrli3:6;1s~~t:i:'6nl&2s)}~t ·:,.
Create'Tijr~ad(i-iuLL~Q, :c,S;};;~.A,_~'\... ':'"i'
.: ,'.~-·... . ::.• ,.
· . • . 1'.-.. "< I '' •• · :., -C. . . " · •.." · ..., . , ... ;; •\
. .
·(LPTHREAD :.START ROUTINE)' -'P'rbtess•
.>"· -<_.'>: '"_\'·/~_:--·, ,,/·,C,-.,:..,..;;, ,,_,, ?•·¥·· ;' ,.. ; :.·..;
A, :
(LPVPID}g,:Q;Hd)7_ . ... . ,''
CreateThread (NULL, 0,
. (LPTHREAP~q1~tT_:);WUTINEJ Process B,
(LPVOID) 0, O; &1d); ·, \ . - .
Sleep (100'000);
return 0;

Here the shared resource is the shared variable 'counter'. The concurrent access to this variable by ,v
the threads 'Process A' and 'Process_B' may create race condition and may produce incorrect results.
The critical section object 'CS' holds the piece of code corresponding to the access of the shared vari- J.
able 'counter' by each threads. This ensures that the memory area containing the low level instructions
corresponding to the high level instruction 'counter-!-+' is accessed exclusively by threads 'Process_A'
and 'Process_B' and avoids a race condition. The output of the above piece of code when exe.cuted on
Windows XP machine is given in Fig. 10.36.
The final value of 'counter' 1s obtained as l 0, which is the expected result for this piece of code.
If you observe this output windO\v you can see that the text is not outputted to the o/p window in the
expected manner. The printl Olibrary routine used in this sample code is re-entrant and it can be pre-
empted while in execution. That is why the outputting of text happened in a non expected way.
Note , ,._,.,',

It should be noted that the scheduling of the threads 'Process_A' and 'Process _B' is OS kernel sched{~
uling policy dependent and you may not get the same output all the time when you run this pieceot
code under Windows XP.
 Real-Time Operating System (RTOS) based Embedded System Design

The critical section object makes the piece of code residing inside it non-reentrant. Now let's try the
above piece of code by putting the printf Olibrary routine in the critical section object.
J <stdio•.11>
;"~,; <wit1dows. h>
'Ii'.i.'*'* ***~
i** * * ** * ** * ****** ** *** ** *** *!'* ** **** ** ** ~*
s an int1:;ger variable 9-nd Buff;ris
twq threads Process A and Process B
er [ ro] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
counter
... = O;
criiical section

.'k ** * * * * **'* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
li'iid Thread 1
(void) {

i;
=O; i <5; · i ++)

if (Buffer[ii > 0)
{
//Use critical section obiect for synchronisation
EnterCriticalSection(&CS);
counter++;
printf("Process A: Counter %d\n",counter);
LeaveCriticalSection(&CS);
}
 Introduction to Embedded Systems

// Child Thr~ad 2
void Process B(vt).id} {
'--~/~(; ,··,

int j;
·for (j = 5; j'<:1,.-(f;\j++)

·rr cB~ff~,r:'u'
{. '
I /us·J .. c·r±
' ,., ~- / ..-·· )_>":'' •:
:i.3ectlo'h bbjk.ct, foi :;s'ynch'i,oni~a·
· Entei.Cff -~~i:;-ion,'X'&CS)}, . :::,'; ; :: '/ .,, .· · · ·
'':'.'.}<\'' .\:-·._:;;.·, -

'.C61.lrttfe ,rf <'..~.:, ..-i~:.-.{f··.<..._•.. ~--

p}i~tfii,. ii :s .tlooriter - ~'.<i\ri", couriter) ;
•,, Leaveck.C siction 'iic's') ;
} , ·, '., '
//*i!*!~***~*~*f***;***********************************;
l I i:Main
-,,.,,_-,,,·.,;.,,· .,.:Thtead
. ;·. ·

DWORD id;

//Initia1tze critical section object

Irii tializecrl ticalSection (&CS) ;
CreateTlfread (NULL, 0, _"
(LPTHREAD_START_ROUTINE)Process .A,.
(LPVOID) 0, 0, &id);
CreateThread(NULL,O,
(LPTHREAD_START ROUTINE)Process
(LPVOID)O,O,&id);
Sleep.(100000);
return D;

The output of the above piece of code when executed on a Windows XP machine is given below.

( Fig. 10.37) Output of the "#'in32__iipplication resolving racing condition through critical section object
 Real Time Operating System (RTOS) based Embedded System Design

~k· ..
t.11:'..1\~:-,;},. ~;,_ ,·_:'.• - · .·:., _-)-,,.,,. ~:~·'.' :;.t ~_x-· ._,,'
'JFtishould
... ,, .
be noted that the scbedulinl!v of the threads 'Process- A' and 'Process
. -
B' is.·::: OS.:kemel sc" .d~
·.,¼ -· si;~y0,:;r..:-:_·ttf::··: :t>· ~-v 2

olicy dependent and you may not get the same output all the time \;fhen yq~ · ;. ··· ·· i{ '" :bf
Windows XP. The output of the above prograrp. when executed at three diffei~n. .Jiµ~~~·:ef
s
given shown in Fig. 10.38. · '.· . • · · •.

I ( Fig. 10.38) Illust•?tion

Events Event 1·;.

er schecl.uler behaviour under Windows XP kernel

. ~·:11,1111sat1on technique which uses the notification mechanism for

synchronisation ·, .. , · .··~ut1un we may come across situations which demand the processes
to wait for a u1 , .11 :,·, it:,; operations. A typical example of this is the producer consum-
er threads, whei ; h, , • "1,11 ,. , 1111 :J1ould wan for the consumer thread to produce the data and
producer thread , 1 " ,11 1 ,, ,11 1 i!h. umsumer thread to consume the data before producing fr\;sh data.
11

If this sequence ,. :, . \1 1 ,\ 11!

1 up 111 producer-consumer problem. Notification mechanism
is used for hand 1 • ,· 1, l' Ill: \ are used for implementing notification mechanisms.
 Introduction to Embedded Systems

A thread/process can wait for an event and another thread/process can set this event for processing by ti
the waiting thread/process. The creation and handling of event objects for notification is OS kernel
dependent. Please refer to the Online Leaming Centre for information on the usage of 'Events' under V
Windows Kernel for process/thread synchronisation.
The MicroC/OS-II kernel also uses 'events' for task synchronisation. We will discuss it in a later C
chapter.
I-
I

Device driver is a piece of software that acts as d

a bridge between the operating system and the 0
hardware. In an operating system based prod- a
uct architecture, the user applications talk to the s
Operating System kernel for all necessary infor- (
mation exchange including communication with I
the hardware peripherals. The architecture of the s
(
OS kernel will not allow direct device access from
the user application. All the device related access
should flow through the OS kernel and the OS ker-
nel routes it to the concerned hardware peripheral. 1
OS provides interfaces in the form of Application I

Programming Interfaces (APis) for accessing the l

hardware. The device driver abstracts the hard-
ware from user applications. The topology of user
applications and hardware interaction in an RIOS
based system is depicted in Fig. 10.39.
Device drivers are responsible for initiating and managing the communication with the hardware
peripherals. They are responsible for establishing the connectivity, initialising the hardware (setting up
various registers of the hardware device) and transferring data. An embedded product may contain dif-
ferent types of hardware components like Wi-Fi module, File systems, Storage device interface, etc. The
initialis ation of these devices and the protocols required for communicating with these devices may be
1
differer+t. All these requirements are implemented in drivers and a single driver will not be able to sat-
isfy all these. Hence each hardware (more specifically each class of hardware) requires a unique driver
component.
Certain drivers come as part of the OS kernel and certain drivers need to be installed on the fly. For
example, the program storage memory for an embedded product, say NAND Flash memory requires a
NANO Flash driver to read and write data from/to it. This driver should come as part of the OS kernel
image. Certainly the OS will not contain the drivers for all devices and peripherals under the Sun. It
contains only the necessary drivers to communicate with the onboard devices (Hardware devices which
are part of the platform) and for certain set of devices supporting standard protocols and device class
(Say USB Mass storage device or HID devices like Mouse/keyboard). If an external device, whose
driver software is not available with OS kernel image, is connected to the embedded device (Say a
medical device with custom USB class implementation is connected to the USB port of the embedded
product), the OS prompts the user to instal its driver manually. Device drivers which are part of the OS
image are known as 'Built-in drivers' or 'On-board drivers'. These drivers are loaded by the OS at the
 Real-Time Operating System (RTOS) based Embedded System Design

time of booting the device and are always kept in the RAM. Drivers which need to be installed for ac-
cessing a device are known as 'Installable drivers'. These drivers are loaded by the OS on a need basis.
Whenever the device is connected, the OS loads the corresponding driver to memory. When the device
is removed, the driver is unloaded from memory. The Operating system maintains a record of the drivers
corresponding to each hardware.
The implementation of driver is OS dependent. There is no universal implementation for a driver.
How the driver communicates with the kernel is dependent on the OS structure and implementation ..
Different Operating Systems follow different impl~mentatioi:is.
It is very essential to know the hardware interfacing details like the memory address assigned to the
device, the Interrupt used, etc. of on-board peripherals for writing a driver for that peripheral. It varies
on the hardware design of the product. Some Real-Time operating systems like 'Windows CE' support
a layered architecture for the driver which separates out the low level implementation from the OS
specific interface. The low level implementation part is generally known as Platform Dependent Device
(PDD) layer. The OS specific interface part is known as Model Device Driver (MDD) or Logical Device
Driver (LDD). For a standard driver, for a specific operating system, the MDD/LDD always remains the
same and only the PDD part needs to be modified according to the target hardware for a particular class
of devices.
Most of the time, the hardware developer provides the implementation for all on board devices for
a specific OS along with the platform. The drivers are normally shipped in the fonn of Board Support
Package. The Board Support Pac{sage contains low level driver implementations for the onboard pe-
ripherals and OEM Adaptation Layer (0AL) for accessing the various chip level functionalities and ·a
bootloader for loading the operating system. The 0AL facilitates communication between the Operating
System (OS) and the target device and includes code- to handle interrupts, timers, power management,
bus abstraction, generic 1/0 control codes (IOCTLs}, etc. The driver files are usually in the form of a
dll file. Drivers can run on either user space or kernel space. Dnvers which run inI user space are known
as user mode drivers and the drivers which run in kernel space are known as kernel mode drivers. User
mode drivers are safer than kernel mode drivers. If an error or exception occurs in a user mode driver,
it won't affect the services of the kernel. On the other hand, if an exception occurs in the kernel mode
driver, it may lead to the kernel crash. The way how a device driver is written and how the interrupts are
handled in it are operating system and target hardware specific. However regardless of the OS types, a
device driver implements the following:
1. Device (Hardware) Initialisation and Interrupt configuration
2. Interrupt handling and processing
3. Client interfacing (Interfacing with user applications)
The Device (Hardwar~ initialisation part of the driver deals with configuring the different registers
of the device (target hardware). For example configuring the 1/0 port line of the processor as Input or
output line and setting its associated registers for building a General Purpose IO (GPI0) driver. The
interrupt configuration part deals with configuring the intenupts that needs to be associated with the
hardware. In the case of the GPI0 driver, if the intention is to generate an interrupt when the Input line
is asserted, we need to configure the interrupt associated with the 1/0 port by modifying its associated
registers. The basic Interrupt configuration involves thy following.
1. Set the interrupt type (Edge Triggered (Rising/Failing) or Level Triggered (Low or High)), enable
the interrupts and set the interrupt priorities.
2. Bind the Interrupt with an Interrupt Request (IRQ). The processor identifies an interrupt through
IRQ. These IRQs are generated by the Interrupt Controller. In order to identify an interrupt the
interrupt needs to be bonded to an IRQ.
 Introduction to Embedded Systems

3. Register an Interrupt Service Routine (ISR) with an Interrupt Request (IRQ). ISR is the qandler for s
an Interrupt. In order to service an interrupt, an ISR should be associated with an IRQ. Registering C
an ISR with an IRQ takes care of it. C
With these the interrupt con.figuration is complete. If an interrupt occurs, depending on its priority, it
l
is serviced and the corresponding ISR is invoked. The processing part of an interrupt is handled in an
ISR. The whole interrupt processing can be done by the ISR itself or by invoking an Interrupt Service s
Thread (1ST). The IST performs interrupt processing on behalf of the ISR. To make the ISR compact I:
and short, it is always advised to use an IST for interrupt processing. The intention of an interrupt is to j
send or receive command or data to and from the hardware device and make the received. data avail- . (
able to user programs for application specific processing. Since interrupt processing happens at kernel (
level, user applications may not have direct access to the drivers to pass and receive data. Hence fr is
I
the responsibility of the Interrupt processing routine or thread to inform the user applfoations that an
interrupt is occurred and data is available.for further processing. The client interfacing part ofihe device l
driver takes care of this. The client interfacing implementation makes use of the Inter Process commu- I
nication mechanisms supported by the embedded OS for communicating and synchronising with.user I
applications and drivers. For example, to inform a user application that an interrupt is occurred and the 1
data received from the device is placed in ashared buffer, the client interfacing code can signal (or set)
an event. The user application creates the event, registers it and waits for the- driver to signal it. The
driver can share the received data through shared memory techniques. IOCTLs, shared buffers, etc. can
be used for data sharing. The story line is incomplete without performing an interrupt done (Interrupt
processing completed) functionality in the driver. Whenever an interrupt is asserted, while vectoring to
its corresponding ISR, all interrupts of equal and low priorities are disabled. They are re-enable only on
executing the interrupt done function (Same as the Return from Interrupt RETI instruction execution
for 8051) by the driver. The interrupt done function can be invoked at the end of correspo·nding ISR or
1ST.
We will discuss more about device driver development in a dedicated book coming under this book-
senes.

The decision of choosing an RTOS for an embedded design is very crucial. A lot of factors needs to be
analysed carefully before making a decision on the selection of an RTOS. These factors can be either
functional or non-functional. The following section gives a brief introduction to the important func-
tional and non-functional requirements that needs to be analysed in the selection of an RIOS for an
embedded design.
I
10 .10 .1 Functional Requirements
Processor Support It is not necessary that all RTOS 's support all kinds of processor architecture. It
I
d

is essential to ensure the processor support by the RTOS.

Memory Requirements The OS requires ROM memory for holding the OS files and it is normally
stored in a non-volatile memory like FLASH. OS also requires working memory RAM for loading the
OS services. Since embedded systems are memory constrained, it is essential to evaluate the minimal
ROM and RAM requirements for the OS under consideration.
Real-time Capabilities It is not mandatory that the operating system for all embedded systems need
to be Real-time and all embedded Operating systems-are 'Real-time' rn beudviour. The task/process
 Real-Time Operating System (RTOS) based Embedded System Design

scheduling policies plays an important role in the 'Real-time' behaviour of an OS. Analyse the real-time
capabilities of the OS under consideration and the standards met by the operating system for real-time
capabilities.
Kernel and Interrupt Latency The kernel of the OS may disable interrupts while executing certain
services and it may lead to interrupt latency. For an embedded system whose response requirements are
high, this latency should be minimal.
Inter Process Communication and Task Synchronisation The implementation oflnter Process
Communication and Synchronisation is OS kernel dependent. Certain kernels may provide a bunch of
options whereas others provide very limited options. Certain kernels implement policies for avoiding
. priority inversion issues in resource sharing.
Modularisation Support Most of the operating systems provide a bunch of features. At times it m,ay
not be necessary tor an embedded product for its functioning. It is very useful if the OS supports modu-
larisation where in which the developer can choose the ess~ntial modules and re-compile the OS image
for functioning. Windows CE is an example for a highly modular operating system.
Support for Networking and Communication The OS kernel may provide stack implementation
and driver support for a bunch of communication interfaces and networking. Ensure that the OS under
consideration provides support for all the interfaces required by the embedded product.
Development Language Support Certain operating systems include the run .time libraries required
for running applications written in languages like Java and C#. A Java Virtual Machine (JVM) custom-
ised for the Operating System is essential for running java applications. Similarly the .NET Compact
Framework (.NETCF) is required for running Microsoft® .NET applications on top of the Operating
-System. The OS may include these components as built-in component, if,tjot, check the availability of
1
the same from a third party vendor for the OS under consideration. '

10.10.2 Non-functional Requirements

Custom Developed or Off the Shelf Depending on the OS requirement, it is possible to go for
the complete development of an operating system suiting the embedded system needs or use an off
the shelf, readily available operating system, which is either a commercial product or an Open Source
product, which is in close match with the system requirements. Sometimes it may be possible to build
the required features-by customising an Open source OS. The decision on which to select is purely de-
pendent on the development cost, licensing fees for the OS, development time and availability of skilled
resources.
Cost The total cost for developing or buying the OS and maintaining it in terms of commercial prod-
uct and custom build needs to be evaluated before taking a decision on the selection of OS.
Development and Debugging Tools Availability The availability of development and debugging
tools is a critical decision making factor in the selection of an OS for embedded design. Certain Operat-
ing Systems may be superior in perfom1ance, but the availability of tools for supporting the develop-\
ment may be limited. Explore the different tools available for the OS under consideration.
Ease of Use How easy it is to use a commercial RTOS is another important feature that needs to be
considered in the RTOS selection.
 Introduction to Embedded Systems

Mter Sales For a commercial embedded RTOS, after sales in the form of e-mail, on-call services
etc. for bug fixes, critical patch updates and support for production issues, etc. should be analysed thor-'
oughly.

- Summary
✓ The Operating System is _responsible for making the system convenient to use, organise and man~g~. ~Yl!:~\11«,
resources efficiently and properly. ...
. ✓ Processtrask manageme~t, Primary memory management, File system m~ag~ment, V.Q systemffiiXjce·,
· agep:ient, .Secondary Storage Managerri~nt, protection implementation, Time mapagement, 'Interrup,t
etc. ig-e fu,e important services hand!edpy the OS kernel. . . . ,.
✓ The cote of the operating system is known. as krrnel. Depending on th~ implementation of,tht4iff~re~t
'services, the kernel is classified as MonQlithic and Micro. User Space i.s ti.le memory are~jn which use ··... ·.· :
tions are corrlined to run, ~her~as ker,n~l space is the memory area reserved for kernel ~ppl~i;atipns." ..·\, ~t?;f'
✓ Operating systems with a generalised kernel are known as General Purpose OperaHng Systems (GF(JS),·w
ope.rating systems with a specialised kernel with deterministic timing behayiour are known as Real-Time vu.era•r:.•.,
. ing SysteirJs.(RTOS). 1 .. . "
✓ In the operating ~ystem context a task/process is a program, or part of it, in execution. The process ~j:@&iJ:i~f,
of registers, process status, a Program Counter (PC) to point to the next executable instruction of the ~roce~s/; i\
stack for holding the local variables associatt;d with the process and the·code.corresponding to the proc~s~J,,r{;;'
✓ The.different states through which a process·traverses through during its journey from the newly cr~~ted s~teiJp'.),
finished state is known as Process Life Cycle ' - · . ·. · • 'i'
✓ .Process management deals with the creation of a process, setting up the memory space for the proc~ss, l
the process's code into the memory space, allocating system resources, setting up a Process Control Block
for the process and processtermination/deletion. · . . 1 _,
✓ A thread is the primitive that can execute code. It is a single sequential flow of control within a proce·ss. A pro'<c,y~f
may contain multiple threads. The act of concurrent execution of multiple threads under an operating system)s ,
known as multitbreading. · ·· · '
✓ Thread standards are the different standards available for thread creation and management. POSIX, Win32, Javl, '
etc. are the commonly used thread creation and management libraries.
✓ -The ability of a system to execute multiple processes simultaneously is known as multiprocessing, whereas
the ability of an operating system to hold multiple processes in memory and switch the processor (CPU) from
executing one process to another process is known as multitasking. Multitasking involves Context Switching,
Context Saving and Context Retrieval. .
✓ Co-operative multitasking, Preemptive multitasking and Non-preemptive multitasking are the three important
types of multitasking which exist in the Operating system context.
✓ CPU utilisation, Throughput, Tum Around Time (TAT), Waiting Time and Response Time are the important
criterions that need to be considered for the selection of a scheduling algorithm for task scheduling.
✓ Job queue, Ready queue and Device queue are the important queues maintained by an operating system in as-
sociation with CPU scheduling.
✓ First. Come First Served (FCFS)/First in First Out (FIFO), Last Come First Served (LCFS)/Last in First Out
(LIFO), Shortest Job First (SJF), priority based scheduling, etc. are examples for Non-preemptive scheduling,
1 whereas Preemptive SJF Scheduling/Shortest Remainin~ Time (SRT), Round Robin(RR) sched~ling and pri~r~-
ity based scheduling are examples for preemptive scheduling.
✓ .:Processes in a multitasking system falls into either Co-operating or Competing. The co-operating processes share
• I
data for communicating among the processes through Inter Process Communication (IPC), where~s.competing
 Real-Time Operating System (RTOS) based Embedded System Design

processes do not share anything among themselves but they share the system resources like display devices,
keyboard, etc.
✓ Shared memory, message passing and Remote Procedure Calls (RPC) are the important IPC mechanisms through
which the co-operating processes communicate in an operating system environment. The implementation of the
IPC mechanism is OS kernel dependent.
✓ Racing, deadlock, liveloc:k, staivation, producer-consumer problem, Readers-Writers problem and priority inver-
sion are some of the problems involved in shared resource access in task communication through sharing.
✓ The 'Dining Philosophers' 'Problem' is a real-life representation of the deadlock, starvation, livelock and 'Rac-
ing' i~suesinsha.red resource access-in operating system qmtext.
✓ friority inver116rris the .cq11dition in which a medium.priority task gets the CPU for execution, when a high
priority tas;)l'.e.eq~ to wait (or a low priority taskJo release a resource which is shared between th~ high priority
task and the lo)V'.piiQriJ:y task. ·
✓ Priority. in~e,r1tan}:e and Priority ceiling are the two mechanisms for avoiding Priority Inversion in a multitask-
ing environment.
✓ The act of preventing the access of a shared resource by a task/process when it is currently being held by another
task/process is"kriown as mutual exclusion. Mutual exclusion can be implemented through either busy waiting:
(spin lock) or sleep and wakeup technique.
✓ Test-and Set,Flags, etc. are examples of Busy waiting based.mutual exclusion implementation, whereas Serria,;
phores, mutex; Critical Section Objects and events are examples for Sleep and Wakeup based mutual exclusion. ,.
✓ Binary semaphore implements exclusive shared resource access, whereas cou_ntingsemaphor,e limits the concur-
rent access to a s.hared resource, and mutual exclusio,nsemaphore prevents priority inversionin shared.resource
access.
✓ Device driver is c1 piece of software that acts as a bridge between the operating system and the hardware. Device
drivers are- respons1ble for,initiating and managing the corriinunication with.the hardware peripherals.
✓ Various functional and non-functional requirements need to be evaluated before the selection of an RIOS for an
embedded design. '

Keywords )

Operating System A piece of software designed to manage and allocate system resources and execute other
pieces of the software
Kernel The core of the operating system which is responsible for managing the system resources
and the communication among the hardware and other system services
Kernel space The primary memory area where the kernel applications are confined to run
User space The primary memmy area where the user applications are confined to run
Monolithic kernel A kernel with all kernel services run in the kernel space under a single kernel thread
Micro kernel A kernel which inco.rporates only the essential services within the kernel space and the rest
is installed as loadable modules called servers
Real-Time Operat- Operating system with a specialised kernel with a detenninistic timing behaviour
ing System (RTOS)
:Scheduler OS kernel service which deals with the scheduling of processes/tasks
· Hard Real-Time Re<).lstime operating systems that strictly adhere to the timing constraints for a task
Soft Real-Time Real-time· operating systems that does not guarantee meeting deadlines, but, offer the best
to
effort meet the deadline
Task/Job/Process In tlie· operating system context a task/process is a progradi, or part of it, in execution
 Introduction to Embedded Systems

Process Life Cycle The different states through which a process traverses through during its journey from the
newly created state to completed state
Thread The primitive that can execute code. It is a single sequential flow of control within a pro-
cess
Multiprocessing Systems which contain multiple CPUs and are capable of executing multiple processes si-
systems multaneous Iy
Multitasking. The ability of an,operating system, to Ji.old multiple•processes in m~n10ry and switch the\
processor (CPU) from executing op.e pro~;ss to another process . -
Context swit~giµg . : The act of switchiµg CPd ampng;thi;procJsses ~~.chan,git!g the current execution ,.,,..,,,t,,.,,~,
Co:-operativ~ fo)tlth Multitasking model in which a task/proces~ gets a chance when the currently executing
tasliing · · relinquishes the CPU voluntarily. · '. ·
. Preemptive multi- · Multitasking modelin which a c1rrei'.itly running task/process is preempted
taskin~ other task/process .
Non:,pree~pfive .. ... Multitas~ing model in which a tqsk gets a chance to e?(:ecute when the currently
multitasking
' ,, !;·;,, •
. task i;elinquishes the GPU or wheri if enters a wait state ·
First Come First Scheduling policy which sorts the R,eady Queue with FCFS model arici schedules the'fi~~f.
· Served {F<=FS)!first arrived process from the Ready queue for execution .
in First O~f~lFP) ·
Last ComeFitst Scheduling policy wl).ich sorts the Ready Queue with LCFS model and schedules the
Served (LG~S)/Last arrived process from the Ready queue for execution
in.First Out{LIFO)
Shortest Job First · Schyduling policy which sorts the Ready queue with the order of the shortest execution time ·:
(SJF) for process and schedules the process with least estimated execution completion tirr1e from•.;
the Ready queue for executio.n .
Priority based Schedi:ding policy which sorts the Ready queue based on priority and schedules the process··.
Scheduling with highest priority from the Ready queue for execution
Shortest Remaining Preemptive scheduling policy which sorts, the Ready quei~e with the order of the shortest re:.: ·
Time(SRT) maining time for execution completion for process and schedules the process with the least
remaining time for estimated execution completion from the Ready queue for execution
Round Robin Preemptive scheduling policy in which the currently running process is preempted based
on time slice
Co-operating pro- Processes which share data for communicating among them
cesses
Inter Process/Task Mechanism for communicating between co-operating processes of a system
Communication
(IPC)
Shared memory A meinory sharing mechanism used for inter process communication
Message passing lPC mechanism based on exchanging of messages between processes through a message Op(
queue or mailbox 1.
Message queue A queue for holding messages for exchanging between processes of a multitasking system
Mailbox A special implementation of message queue under certain OS kernel, which supports only
a single message
Signal A form of asynchronous message notification
Remote Procedure The IPC mechanism used by a process to invoke a procedure of another,process running on
Call or RPC the same CPU .or on a different CPU which I
is interconnected
• ,.
in a network
: 2
Racing The situation in which multiple processes· compete (race) each other to access and manipu-
1
late shared data concurrently \
/
.
 Real-Time Operating System (RTOS) based Embedded System Design

Deadlock

Star:vation

t:;xf{J ::'•-:.,:-ft.... _· \ji< , ,:;:·\

[(:';
1~cPr1Qnty1~v~,r~10, ·
'' ·; '': . ., ,•;•_:·

~~ri()rittinh,eq~!lq~~- J; ··

l:ri~?;~("'
,,,skkrpce~~ syn-
. nisation
~t~~.·~xcbi~ion _:_ ;:,.,; Cb:

t~f
nel
lii~~;; ·s;:q;~~:r~tiiplenfeiltatidiif6;
· · · · · ·'
ifii~siif;e~Ou;ce acce~s under certain OS ker-
· · ·· · · ·· · ··
'Device driver A piece of software that acts as abridge het-ween tI1t,Eitfe~atirig system 'ano the hardware

Objective Questions

Operating System Basics

I. Which of the following is trne about a kernel?
(a) The kernel is the core of the operating system
(b) It 1s responsible for managing the system resources and the communication among the hardware and other
sys tern services
(c) It acts as the abstraction layer between system, resources and user applications.
(d) It contains a set of system libraries and services
(e) All of these
2. The user application and kernel interface is provided through
(a) System calls
..
(b) Shared memory ·. ;W (d) None of these
 Introduction to Embedded Systems

3. The process management service of the kernel is responsible for

{a) Setting up the memory space for the process
(b) Allocating system resources
(c) Scheduling and managing the execution of the process
(d) Setting up and managing the Process Control Block (PCB), inter-process communication and synchronisa-
tion
(e) All of these
4. The Memory Management Unit (MMU) of the kernel is responsible for
(a) Keeping track of which part of the memory area is currently used by which process
(b) Allocating and de-allocating memory space on a need basis (Dynamic memory allocation)
(c) Handling all virtual memory operations in a kernel with virtual memory support
(d) All of these
5. The meniory area which holds the program code corresponding to the core OS applications/services is known as
· (a) User space (b) Kernel space (c) Shared memory (d) All o"f these
6. Which of the following is true about Privilege separation?
(a) The user applications/processes runs at user space and kernel applications run at kernel space
(b) Each user application/process runs .on its own virtual memory space
(c) A process is not allowed to access th6 memory space of another process directly
(d) · All of these
7. Which of the following is true about monolithic kernel?
(a) All kernel services run in the kernel space under a single kernel thread.
(b) The tight internal integration of kernel modules in monolithic kernel architecture allows the effective utilisa-
tion of the low-level features of the underlying system
(c) Error prone. Any error or failure in any one of the kernel modules may lead to the crashing of the entire
kernel
(d) All of these /
8. Which of the following is true about microkernel?
(a) The microkemel design incorporates only the essential set of operating system services into the kernel-The
rest of the operating system services are implementedin programs known as 'servers' which runs in user
space.
(b) Highly modular and OS neutral
(c) Less Error prone. Any 'Server' where error occurs can be restarted without restarting the entire ~rnel
(d) All of these
Real-Time Operating System (RTOS)
1. Which of the following is true for Real-Time Operating Systems (RTOSes)?
(a) Possess specialised kernel (b) Deterministic in behaviour
(c) Predictable performance (d) All of these
2. Which of the following is (are) example(s) for RTOS?
(a) Windows CE (b) Windows XP (c) Windows 2000 (d) QNX
(e) (a) and (d)
3. Interrupts which occur in sync with the currently executing task are known as
(a) Asynchronous interrupts (b) Synchronous interrupts.
(c) External interrupts (d) None of these
4. Which of the following is an example ofa synfhronousinterrupt?
(a) TRAP {b) External interrupt (c) Divide b,y zer'o (d) Timednterrupt
5. Which of the following is true about 'Timer tick' for RTOS? ·. ·
(a) The high resolution hardware,timer interrupt is referred.as 'Timer tick'
(b) The 'Timer tick' is taken as th¢ timing reference by the kernel
(c) The time parameters for tits~ arlil e~pressed as the multiples of the 'Timer tick'
1 1
(d) All of these
 Real-Time Operating System (RTOS) based Embedded System Design

6. Which of the following is true about hard real-time systems?

(a) Strictly adhere to the timing constraints for a task
(b) Missing any deadline may produce catastrophic results
(c) Most of the hard real-time systems are automatic and may not contain a human in the loop
(d) May not implement virtual memory based memory management
(e) All of these.
7. Which of the following is true about soft real-time systems?
(a) Does not guarantee meeting deadlines, but offer the best effort to meet the deadline are referred
(b) Missing deadlines for tasks are acceptable
(c) Most of the soft real-tiine systems contain a human in the loop
(d) All of these
Tasks, Process and Threads
l. Which of the following is true about Process in the operating system context?
(a) ·A 'Process' is a program, or part ofit, in execution
(b) It can be an instance of a program in execution
(c) A process requires various system resources like CPU for executing the process, memory'for storing the code
corresponding to the process and associated variables, I/0 devices for info~ation exchange, etc.
(d) A process is sequential in execution
(e) All of these
2. A process has
(a) Stack memory (b) Program memory (c) Working Registers (d) Data mef@ry
(e) All of these
e 3. The 'Stack' memory of a process holds all temporary data such as variables local to the process. State 'True' or
'False'
(a) True (b) False
4. The data memory of a process holds
.e (a) Local variables (b) Global variables (c) Program instructions (d) None of these
lf 5. A process has its own memory space, when residing at the main memory. State 'True' or 'False'
(a) True (b) False
6. A process when loaded to the memory is allocated a virtual memory space in the range 0x08000 to 0x08FF8. What
is the content of the Stack pointer of the process when it is created?
(a) 0x07FFF (b) Ox08000 (c) 0x08FF7 (d) 0x08FF8
7. What is the content of the program counter for the above example when the process is loaded for the first time?
(a) 0x07FFF (b) 0x08000 (c) 0x08FF7 (d) 0x08FF8
8. The state where a process is incepted into the memory and awaiting the processor time for execution, is known
as
(a) Created state (b) Blocked state (c) Ready state (d) Waiting state
(e) Completed state
9. The CPU allocation for a process may change when it changes its state from _ _ _?
(a) 'Running' to 'Ready' (b) 'Ready' to 'Running'
(c) 'Running' to 'Blocked' (d) 'Running'to 'Completed'
(e) All of these
10. Which of the following is true about threads?
(a) A,thread is the primitive that can execute code
(b) A thread is a single sequential flow of control within a process
(c) 'Thread' is also known as lightweight process
(d) All of these (e) None of these
11. A process can have many threads of execution. State 'True' or 'False'
(a) True · (b) False
 Introduction to Embedded Systems

12. Different threads, which are part of a process, share the same address space. State 'True' or 'False'
(a) True (b) False
13. Multiple threads of the same process share _ _ _?
(a) Data memory (b) Code memory
(c) Stack memory (dJ All of these
(e) only (a) and (b)
14. Which of the following is true about multithreading?
(a) Better memory utilisation
(b) Better CPU utilisation
(c) Reduced complexity in inter-thread communication
(d) Faster process execution (e) All of these
15. Which of the following is a thread creation and management library?
(a) POSIX · (b) Win32
(c) Java Thread Library (d) All of these
16. Which of the following is the PO SIX standard library for thread creation and management
(a) Pthreads (b) Threads (c) Jthreads (d) None of these
17. What happens when a thread object's waitO method is invoked in Java?
(a) Causes the thread object to wait
(b) The thread will remain in the 'Wait' state until another thread invokes the notifyO or notifyAllO method of the
thread object which is waiting
(c) Both of these
(d) None of these
18. Which of the following is true about user level threads?
(a) Even if a process contains multiple user level threads, the OS treats it as a single thread
(b) The user level threads are executed non-preemptively in relation to each other
(c) User level threads follow co-operative execution model
(d) All of these
19. Which of the following are the valid thread binding models for user level to ke'rnel level thread binding?
(a) One to Many (b) Many to One (c) One to One (d) Many to Many
(e) All of these (f) only (b), (c) and (d)
20. If a thread expires, the stack memory al,located to it is r$claimed by the process to which the thread belongs. State
'True' or 'False'
(a) True (b) False
Multiprocessing and Multitasking
L Multitasking and multiprocessing refers to the same entity in the operating system context. S,tate 'True' or 'False'
(a) True (b) False
2. Multiprocessor systems contain .
(a) Single CPU (b) Multiple CPUs (c) No CPU
3. The ability of the operating system to have multiple programs in memory, which are ready for execution, is re-
ferred as
(a) Multitasking (b) Multiprocessing (c) Multiprogramming
4. In a multiprocessing system
(a) Only a single process can run at a time (b) Multiple processes can run simultaneously
(c) Multiple processes run in pseudo parallelism
5. In a multitasking system
(a) Only a single process can run at a time (l;>) Multiple processes can run simultaneously
(c) Multiple processes nm in pseudo parallelism (d) Only (a) and (c)
6. Multitasking involves
(a) CPU execution switching of processes (b) CPU halting (c) No CPU operation
 Real-Time Operating System (RTOS) based Embedded System Design

7. Multitasking involves
(a) Context switching (b) Context saving (c) Context retrieval (d) All of these
(e) None of these
8. What are the different types of multitasking present in operating systems?
(a) Co-operative (b) Preemptive (c) Non-preemptive (d) All of these
9. In Co-operative multitasking, a process/task gets the CPU time when
(a) The currently executing task tenninates its execution
(b) The currently executing task enters 'Wait' state
(c) The currently executing task relinquishes the CPU before tenninating
(d) Never get a chance to execute (e) Either (a) or (c)
10. In Preemptive multitasking
(a) Each process gets an equal chance for execution
(b) The execution of a process is preempted based on the scheduling policy
(c) Both of these (d)_ None of these
11. In Non-preemptive multitasking, a processitask gets the CPU time when
(a) The currently executing task tenninates its execution
(b) The currently executing task enters 'Wait' state
(c) The currently executing task relinquishes the CPU before terminating
(d) All of these
(e) None of these
12. MSDOS Operating System supports
(a) Single user process with single thread
(b) Single user process with multiple threads
(c) Multiple user process with single thread per process
(d) Multiple user process with multiple threads per process
Task Scheduling
1. Who detennines which task/process is to be executed at a given point of time?
(a) Process manager (b) Context manager (c) Scheduler (d) None of these
2. Task scheduling is an essential part of multitasking.
(a) True (b) False
3. The process scheduling decision may take place when a process switches its state from
(a) 'Running' to 'Ready' (b) 'Running' to 'Blocked'
(c) 'Blocked' to 'Ready' (d) 'Running' to 'Completed'
(e) All of these
(t) Any one among (a) to (d) depending on the type of multitasking supported by OS
4. A process switched its state from 'Running' to 'Ready' due to scheduling act. What is the type of multitasking
suppo1ted by the OS?
(a) Co-operative (b) Preemptive (c) Non-preemptive (d) None of these
5. A process switched its state from 'Running' to 'Wait' due to scheduling act. What is the type of multitasking sup-
ported by the OS?
(a) Co-operative (b) Preemptive (c) Non-pre(emptive (d) (b) or (c)
6. Which one ofthe following criteria plays an important role in the selection of a scheduling algorithm?
(a) CPU utilisation (b) Throughput (c) Turnaround time (d) Waiting time
(e) Response time (f) All of these
7. For a good scheduling algorithm, the CPU utilisation is
(a) High (b) Medium (c) Non-defined
 Introduction to Embedded Systems

8. Under the process scheduling context, 'Throughput' is

(a) The number of processes executed per unit of time
(b) The time taken by a process to complete its execution
(c) None of these
9. Under the process scheduling context, 'Turnaround Time' for a process is
(a) The time taken to complete its execution (b) The time spent in the 'Ready' queue
(c) The time spent on waiting on 1/0 (d) None of these
10. Turnaround Time (TAT) for a process includes
(a) The time spent for waiting for the main memory (b) The time spent in the ready queue
(c) The time spent on completing the 1/0 operations (d) The time spent in execution
(e) All of these
11. For a good scheduling algorithm, the Tum Around Time (TAT) for a process should be
(a) Minimum (b) Maximum (c) Average (d) Varying
12. Under the process scheduling context, 'Waiting time' for a process is
(a) The time spent in the 'Ready queue'
(b) The time spent on 1/0 operation (time spent in wait state)
(c) Sum of (a) ~nd (b)
(d) None of the~e
13. For a good scheduling algorithm, the waiting time for a process should be
(a) Minimum (b) Maximum (c) Average (d) Varying
14. Under tµe process scheduling context, 'Response time' for a process is
(a) The time spent in 'Ready queue'
(b) The time between the submission of a process and the first response
(c) The time spent on I/0 operation (time spent in wait state)
(d) None of these
15. For a good scheduling algorithm, the response time for a process should be
(a). Maximum (b) Average (c) Least (d) Varying
16. What are the different queues associated with process scheduling?
(a) Ready Queue (b) Process Queue (c) Job Queue (d), Device Queue
(e) AlloftheAbove (f) (a),(c)and(d)
17. The 'Ready Queue' contains
(a) All the processes present in the system (b) All the processes which are 'Ready' for execution
(c) The ctmently running processes (d) Processes which are waiting for I/0
18. Which among the following scheduling is (are) Non-preemptive scheduling
(a) First In First Out (FIFO/FCFS) (b) Last In First Out (LIFO/LCFS)
(c) ShortestJob First (SJF) (d) All of these
(e) None of these
19. Which of the following is true about FCFS scheduling
(a) Favours CPU bound processes (b) The device utilisation is poor I

(c) Both of these (d) None of these

20. The average waiting time for a given set of process is ---~- in SJF scheduling compared to FIFO scheduling
I
(a) Minimal (b) Maximum (c) Average
21. Which among the following scheduling is (are) preemptive scheduling
(a) Shortest Remaining Time First (SRT) (b) Preemptive Priority based
(c) Round Robin (RR) (d) All of these
(e) None of these
22. The Shortest Job First (SJF) algorithm is a priot'ity based scheduling. State 'True' or 'False'
(a) True (b) False
 Real-Time Operating System (RTOS) based Embedded System Design

23. Which among the following is true about preemptive scheduling

(a) A process is moved to the 'Ready' state from 'Running' state (preempted) without getting an explicit request
from the process
(b) A process is moved to the 'Ready' state from 'Running' -state (preempted) on receiving an explicit request
from the process
(c) A process is moved to the 'Wait' state. from the 'Running'_ state without getting an explicit request from the
process
(d) None of these
24. Which of the following scheduling technique(s) possess the drawback of 'Starvation'
(a) Round Robin ·· · (b) Priority based preemptive
(c) Shortest Job First (SJF) {d) (b) and (c)
(e) None of these
25. Starvation describes the condition in which
(a) A process is ready to execute and is waiting in the 'Ready' queue for a long tin:ie and is unable to get the CPU
time due fo various reasons
(b) A process is waiting for a shared resource for a long time, and is unable to get it for various reasons.
(c) Both of the above
(d) None of these
26. Which of the scheduling policy offers equal opportunity for execution for ~11 processes?
(a) Priority based scheduling (b) Round.Robin (RRfscheduling
(c) Shortest Job First (SJF) · (d) All of these
(e) None of these
27. Round Robin (RR) scheduling commonly uses which one of the following poiicies for sorting the 'Ready'
queue?
(a) Priority (b) FCFS (FIFO) · (c) LIFO (d) SRT
(e) SJF
28. Which among the following is used for avoiding 'Starvation' ofprocesses in priority based scheduling?
(a) Priority Inversion (b) Aging (c) Priority Ceiling (d) All of these
29. Which of the following is true about 'Aging' ·
(a) Changes the priority of a process' at run time
(b) Raises the priority of a process temporarily
(c) It is a technique used for avoiding 'Starvation' of processes
(d) All of these
(e) None of these
30. Which is the most commonly used scheduling policy in Real-Time Operating Systems?

l (a) Round Robin (RR) (b) Priority based preemptive

(c) Priority based non-preemptive
(d) Shortest Job first (SJF)

I
31. In the process scheduling context, the IDLE TASK is executed for
(a) To handle system interrupts
(b) To keep the CPU always engaged or to keep the CPU in idle mode d'epending on the system design
(c) To keep track of the resource usage by a process
(d) All of these
Task Communication and Synchronisation
1. Processes use IPC mechanisms for
(a) Communicating between process (b} Synchronising the access of shared resource
(c) Both of these (d) None of the.se
2. Which of the following techniques is used by operating systems for inter p~ocess cpmmunication?
(a) Shared memory (b). Messaging (c) Signalling (d) All of these
 · Introduction to Embedded Systems

3. Under Windows Operating system, the input and output buffer memory for a named pipe is allocated in
(a) Non-paged system memory (b) Paged system memory
(c) Virtual memory (d) None of the above
4. Which among the following techniques is used for sharing data between processes?
(a) Semaphores (b) Shared memory (c) Messages d) (b) and (c)
5. Which among the following is a shared memory technique for IPC?
(a) Pipes (b) Memory mapped Object
(c) Message blocks (d) Events (e) (a) and (b)
6. Which of the following is best advised for sharing a memmy mapped object between processes under windows
kernel?
(a) Passing the handle of the shared memory object (b) Passing the name of the memory mapped object
(c) None of these
7. Why is message passing relatively fast compared to shared memory based IPC?
(a) Message passing is relatively free from synchronisation overheads
(b) Message passing does not involve any OS intervention
(c) All of these --'.
(d) None of these
8. In asynchronous messaging, the message posting thread just posts the message to the queue and will not wait for
an acceptance {return) from the thread to which the message is posted. State 'True' or 'False'
(a) True (b) False
9. Which of the following is a blocking message passing call in Windows?
(a) PostMessage (b) PostThreadMessage (c) SendMessage (d) All of these
(e) None of these .
10. Under Windows operating system, the message is passed through _ _ for Inter Pro<;:ess Communication
(IPC) oetween processes?
(a) Message structure (b) Memory 111/lpped object
(c) Semaphore (d) All of these
·11. Which of the following is true about 'Signals' for Inter Process Communication?
(a) Signals are used for asynchronous notifications (b) Signals are not queued
(c) Signals do not carry any data (d) All of these
12. Which of the following is true about Racing or Race co_nditior,?
(a) It is the condition in which multiple processes compete (race) each other to access and manipulate shared data
concurrently
(b) In a race condition the final value of the shared data depends on the process which acted on the data finally
(c) Racing will not occur if the shared data access is atomic
(d) All of these
13. Which of the following is true about deadlock?
(a) Deadlock is the condition in which a process is waiting for a resource held by another process which is wait-
ing for a resource held by the first process
(b) Is the situation in which none of the competing process will be able to access the resources held by other
processes since they are locked by the respective processes
(c) Is a result of chain of circular wait
(d) All of these
14. What are the conditions favouring deadlock in multitasking?
(a) Mutual Exclusion (b) Hold and Wait .(c) No ker6.elresource preemption at kernel level
(d) Chain of circular waits (e) All of these
15. Livelock describes the situation where
(a) A pi:~cess waits on a resource is not blocked on it and it maises frequent attempts to acquire the resource. But.
1

unable to acquire it since it is held

I
by other process
 Real-Time Operating System (RTOS) based Embedded System Design

(b) A process waiting in the 'Ready' queue is unable to get the CPU time for execution
(c) Both of these
(d} None of t~ese
16. Priority inversion is
(a) The condition in which a high priority task needs to wait for a low priority task to release a resource which is
shared between the high priority task and the low priority task
(b) The act of increasing the priority of a process dynamically .
(c) The act of decreasing the priority of a process dynamically
(d) All of these
17_. Which of the following is true about Priority inheritance?
(a) A low priority task which currently holds a shared resource requested by a high priority task temporarily
inherits the priority of the high priority task
(b) The priority of the low priority task which is temporarily boosted to high is brought to the original value when
it releases the shared resource
(c) All of these
(d) None of these
18 ..Which of the following is true about Priority Ceiling based Priority inversion handling?
(a) A priority is associated with each shared resource
(b) The priority associated to each resource is the priority of the highest priority task which- uses th1s shared
resource
(c) Whenever a task accesses a shared resource, the scheduler elevates the priority ofthe task to that of the ceiling
priority of the resource
(d) The priority of the task is brought back to the original level once the task completes the accessing of the
shared resource
(e) All of these
19. Process/Task synchronisation is essential for?
(a) Avoiding conflicts in resource access in multitasking environment
(b) Ensuring proper sequence of operation across processes.
(c) Communicating between processes
(d) All of these
(e) None of these
20. Which of the following is true about Critical Section?
(a) It is the code memory area which holds the program instructions (piece of code) for accessing a shared
resource
(b) The access to the critical section should be exclusive
(c) All of these
(d) None of these
21. Which of the following is true about mutual exclusion?
(a) Mutual exclusion enforces mutually exclusive access of resources by processes
(b) Mutual exclusion may lead to deadlock
(c) Both of these
(d) None of these
22. Which of the following is an example of mutual exclusion enforcing policy?,
(a) Busy Waiting (Spin lock) (b) Sleep {k Wake up
(c) Both of these (d) None of these
23. Which of the following is true about lock based synchronisation mechanism?
(a) It is CPU intensive
(b) Locks are useful in handling situations where the processes is likely to be blocked for a shorter period of time
on waiting the lock · ' :· '
 Introduction to Embedded Systems

(c) If the lock is being held for a long time by a process and if it is preempted by the OS, the other threads waiting
for this lock may have to spin a longer time for getting
(d) All of these
(e) None of these
24. Which of the following synchronisation techniques follow the 'Sleep & Wakeup' mechanism for ·mutual exclu-
sion? 1
(a) Mutex (b) Semaphore (c) Critical Section (d) Spin lock
(e) (a), (b) and (c)
25. Which of the following is true about mutex objects for IPC synchronisation under Windows OS?
(a) Only one process/thread can own the 'mutex object' at a time
(b) The state of a mutex object is set to non-signalled when it is not owned by any process/thread, and set to
signalled when it is owned by any process/thread
(q) The state of a mutex object is set to signalled when it is not owned by any process/thread, and set to non-sig-
nalled when it is owned by any process/thread
(d) Both (a)&(b) (e) Both(a)&(c)
26. Which of the following is (are) the wait functions provided by windows for synchronisation purpose?
(a) WaitForSingleObject (b) WaitForMultipleObjects
(c) Sleep (d) Both (a) and (b)
27. Which of the following is true about Critical Section object?
(a) It can only be used by the threads of a single process (Intra process)
(b) The 'Critical Section' must be initialised before the threads of a process can use it
(c) Accessing Critical Section blocks the execution of the caller t!iread if the critical section is already in use by
other threads
(d) Threads which are blocked by the Critical Section access call, waiting on a critical section, are added to a wait
queue and are woken when the Critical Section is available to the requested thread
(e) All of these
28. Which of the following is a non-blocking Critical Section accessing call under windows?
(a) EnterCriticalSection (b) TryEnterCriticalSection
(c) Both of these (d) None of these
29. The Critical Section object makes the piece of code residing inside it
(a) Non-reentrant (b) Re-entrant (c) Thread safe (d) Both (a) and (c)
30. Which of the following synchronisation techniques is exclusively used for synchronising the access of shared
resources by·the threads of a process (Intra Process Synchronisation) under Windows kernel?
(a) Mutex object (b) Critical Section object (c) Interlocked functions
(d) Both (c) and (d)

Review Questions
Operating System Basics
1. What is an Operating System? Where is it used and what are its primary functions?
2. What is kernel? What are the different functions handled by a general purpose kernel?
3. What is kernel space and user space? How is kernel space and user space interfaced?
4. What is monolithic and microkernel? Which one is widely uhed in real-tim~'operating systems?
. ' I
5. What is the difference between a General Purpose kernel ~d a Real-Time k~rnel? µive an example for both.
I

Real-Time Operating System (RTOS)

1. Explain the basic functions of a teal-time kernel?
2, What is task control block (TCB)? Explain the-structure ofTCB
 Real-Time Operating System (RTOS) based Embedded System Design·

3. Explain the difference between the memory management of general purpose kernel and real-time kernel.
4. What is virtual memory? What are the advantages and disadvantages, of virtual memory?
5. Explain how 'accurate time management' is achieved in real-time kernel
6. What is the difference between 'Hard' and 'Soft' real-time systems? Give an example for 'Hard' and 'Soft' Real-
Time kernels
Tasks, Process and Threads
l. Explain Task in the operating system context
2. What is Process in the operating system context?
3. Explain the memory architecture of a process
4. What is Process Life Cycle?
5. Explain the various activities involved in the creation of process and threads
6. What is Process Control Block (PCB)? Explain the structure of PCB
7. Explain Process Management in the Operating System Context
8. What is Thread in the operating system context?
9. Explain how Threads and Processes are related? What are common to Process and Threads?
10. Explain the memory model of a 'thread'.
11. Explain the concept of 'multithreading'. What are the advantages of multithreading?
12. Explain how multithreading can improve the performance of an application with an illustrative example
13. Why is thread creation faster than process creation?
14. Explain the commonly used thread standards for thread creat1on and management by different operating systems
15. Explain Thread context switch and the various activities performed in thread context switching for user level and
kernel level threads
16. What all information is held by the thread control data structure of a user/kernel thread?
17. What are the differences between user level and kernel levef threads?
18. What are the advantages and disadvantages of using user level threads?
_19. Explain the different thread binding models for user and kernel level threads
20. Compare threads and processes in detail
Multiprocessing and Multitasking
.L Explain multiprocessing, multitasking and multiprogramming
2. Explain context switching, context saving and context retrieval
3. What all activities are involved in context switching?
4. Explain the different multitasking models in the operating system context
Task Scheduling
1. What is task scheduling in the operating system context?
2. -Explain the various factors to be considered for the selection of a scheduling criteria
3. Explain the different queues associated with process scheduling

I
4. Explain the different types of non-preemptive scheduling algorithms. State the merits and de-merits of each
5. Explain the different types of preemptive scheduling algorithms. State the merits and de-merits of each
6. Explain Round Robin (RR) process scheduling with interrupts
7. Explain starvation in the process scheduling context. Explain how starvation can be effectively tackled?
/ 8. What is IDLEPROCESS? What is the significance of IDLEPROCESS in the process scheduling context?
9. Three processes with process IDs PI, P2, P3 with estimated completion time 5, 10, 7 milliseconds respectively
·enters the ready queue together in the order Pl, P2, P3. Process P4 with estimated execution completion time 2
milliseconds enters the ready queue after 5 milliseconds. Calculate the waiting time and Tum Around Time (TAT)
for each process and the Average waiting time_ and Turn Around Time (Assuming there is no I/0 waiting for the
processes) in the FIFO scheduling
10. Three processes with process IDs Pl, P2, P3 with estimated completion time 12, 10, 2 milliseconds respectively
enters the ready queue together in the order P2, P3, Pl. Process P4 with estimated execution completion time

..
 Introduction to Embedded Systems

4 milliseconds enters the Ready queue after 8 milliseconds. Calculate the waiting time and Tum Around Time
· (TAT) for each process and the average waiting time and Tum Around Time (Assuming there is no I/0 waiting for
the processes) in the FIFO scheduling
11. Three processes with process IDs Pl, P2, P3 with estimated completion time 8, 4, 7 milliseconds respectively
_ enters the ready queue together in the order P3, Pl, P2. Pl contains an I/0 waiting time of 2 milliseconds when it
completes 4 milliseconds of its execution. P2 and P3 do not contain any I/0 waiting. Calculate the waiting time
and Tum Around Time (TAT) for each process and the average waiting time and Tum Around Time in the LIFO
scheduling. All the estimated execution completion time is excluding I/0 wait time
12. Three processes with process IDs Pl, P2, P3 with estimated completion time)2~ 10, 2 milliseconds respectively
enters the ready queue together in the order P2, P3, P 1. Process P4 with estimated execution completion time 4
milliseconds enters the Ready queue after 8 milliseconds. Calculate the waiting time and Turn Around Time (TAT)
for each process and the Average waiting time and Turn Aroun,d Time (Assuming there is no I/0 waiting for the
processes) in the LIFO scheduling
13. Three processes with process IDs Pl, P2, P3 with estimated completion time 6, 8, 2 milliseconds respectively
enters the ready queue together. Process P4 with estimated execution completion time 4 milliseconds enters the
Ready queue after 1 millisecond. Calculate the waiting time and Tum Around Time (TAT) for each process and
the Average waiting time and Turn Around Time (Assuming there is 1\0 I/0 waiting for the p1;ocesses) in the non-
preemptive SJF scheduling
14. Three processes with process IDs Pl, P2, P3 with estimated completion time 4, 6, 5 milliseconds and priorities 1,
0, 3 (0-highest priority, 3 lowest priority) respectively enters the ready queue together: Calculate the waiting time
and Turn Around Time (TAT) for each process and the average waiting time and Tum Around Time (Assuming
there is no I/0 waiting for the processes) in non-preemptive priority based scheduling algorithm
15. Three processes with process IDs Pl, P2, P3 with estimated completion time 4, 6, 5 milliseconds and priorities
1, 0, 3 (0-highest priority, 3 lowest priority) respectively enters the ready queue together. Process P4 with es••
timated execution completion time 6 milliseconds and priority 2 enters the 'Ready' queue after 5 milliseconds.
Calculate the waiting time and Tum Around Time (TAT) for each process and the average waiting time and Turn
Around Time (Assuming there is no I/0 waiting for the processes) in non-preemptive priority based scheduling
algorithm
H:l. Thre~ processes with process IDs Pl, P2, P3 with estimated completion time 8, 4, 7 milliseconds respectively en- ·
ters the ready queue together. Pl contains an I/0 waiting time of2 milliseconds when it completes 4 milliseconds
of its execution. P2 and P3 do not contain any I/0 waiting. Calculate the waiting time and Tum Around Time (TAT)
for each process and the average waiting time and Tum Around Time in the SRT scheduling. All the estimated
execution completion time is excluding I/0 waiting time
17. Three processes with process IDs Pl, P2, P3 with estimated completion time 12, 10, 6 milliseconds respectively
enters the ready queue together. Process P4 with estimated execution completion time 2 milliseconds enters the
Ready queue after 3 milliseconds. Calculate the waiting time and Tum Around Time (TAT) for each process and
the Average waiting time and Turn Around Time (Assuming there is no I/0 waiting for the processes) in the SRT
scheduling
18. Three processes with process IDs Pl, P2, P3 with estimated completion time 10, 14, 20 milliseconds respectively,
enters the ready queue together in the order P3, P2, Pl. Calculate the waiting time and Tum Around Time (TAT)
for each process and the Average waiting time and Turn Around Time (Assuming there is no I/0 waiting for the
processes) in RR algorithm with Time slice = 2 ms
19. Three processes with process IDs Pl, P2, P3 with estimated completion time 12, 10, 12 milliseconds respectively
enters the ready queue together in the order P2, P3, Pl. Process P4 with estimated execution completion time 4
milliseconds enters the Ready queue after 8 milliseconds. Calculate the waiting time and Turn Around Time (TAT)
for each 'Process and the Average waiting time and Tum Around Time (Assuming there is no I/0 waiting for the
processes) in RR algorithm with Time slice 4 ms
20. Three processes with process IDs Pl, P2, P3_with estimated completion time 4, 6, 5 milliseconds and priorities 1,
0, 3 (0-titfighe_~t_p_tio~ty, 3 lo"'.~st nrioritv) respectively enters the ready queue ·together. Calculate the waiting time
-· : . , ~" -
 Real-Time Operating System (RTOS) based Embedded System Design

and Turn Around Time (TAT) for each process and the average waiting time and Turn Around Time (Assuming
there is no I/0 waiting for the processes) in preemptive priority based scheduling algorithm
21. Three processes with process IDs Pl, P2, P3 with estimated completion time 6, 2, 4 milliseconds respectively,
enters the ready queue together in the order Pl, P3, P2. Process P4 with estimated execution time 4 milliseconds
entered the 'Ready' queue 3 milliseconds later the start of execution of P1. Calculate the waiting time and Turn
Around Time (TAT) for each process _and the Average waiting time and Tum Around Time (Assuming there is no
1/0 waiting for the processes) in RR algorithm with Time slice 2 ms
Task Communication and Synchronisation
I. Explain the various process interaction models i}\ detail.
2. What is Inter Process Communication (IPC)? Give an overview of different IPC mechanisms adopted by various
operating systems. ·
3. Explain how multiple processes in a system co-operate:
4. Explain how multiple threads of a process co-operate.
5. Explain the shared memory based IPC.
6. Explain the concept of memory mapped objects for IPC.
7. Explain the handle -sharing and name sharing based memocy mapped object technique for IPC under Windows
Operating System.
8. Explain the message passing technique for IPC. What are the merits and de-r6.erits of message based IPC?
-9. Explain the synchronous and asynchronous messaging mechanisms for IPC under Windows kernel.
I 0. Explain Race condition in detail, in relation to the shared resource access.
11. What is deadlock? What are the different conditions favouring deadlock?
12. Explain by Coffman conditions?
13. Explain the different methods of handling deadlocks.
14. Explain livelock in the resource sharing context.
15. Explain starvation in the resource sharing context.
16. Explain the Dining Philosophers problem in the process·synchronisation context.
17. Explain the Produces-consumer problem in the inter process communication context.
18. Explain bounded-buffer problem in the interprocess communication context.
19. Explain buffer overrun and buffer under-run.
20. ·What is priority inversion? What are the different techniques adopted for handling priority inversion?
21. What are the merits and de-merits of priority ceiling?
22. Explain the different task~omnmnication SY!].Chronisation issues encountered in Interprocess Communication
23. What is task (process) synchronisation? What is the role of process synchronisation in IPC?
24. What is mutual exclusion in the process synchronisation context? Explain the different mechanisms for mutual
exclusion
25. What are the merits and de-merits of busy-waiting (spinlock) based mutual exclusion?
26. Explain the Test and Set Lock (TSL) based mutual exclusion technique. Explain how TSL is implemented in Intel
family of processors
27. Explain the interlocked functions for lock based mutual exclusion under Windows OS
-28. Explain the advantages and limitations of interlocked function based synchronisation under Windows
29. Explain the sleep & wakeup mechanism for mutual exclusion
30. What are the merits and de-merits of sleep & wakeup mechanism based mutual exclusion?
31. What is mutex?
32. Explain the mutex based process synchronisation under Windows OS
33. What is semaphore? Explain the different types of semaphores. Where is it used?
34. What is binary semaphore? Where is it used?
35. What is the difference between mutex and semaphore?
36. What is the difference between semaphore and.binary semaphore?
37. What is the difference between mutex and binary semaphore?
 Introduction to Embedded Systems

38. Explain the semaphore based process synchronisation under Windows OS

39. Explain the critical section problem?
40. What is critical section? What are the different techniques for contr?lling access to critical section?
41. Explain the critical section object for process synchronisation. Why is critical section object based synchronisation
fast?
42. Explain the critical section object based process synchronisation under Windows OS.
43. Explain the Event based synchronisation mechanism for IPC.
44. Explain the Event object based synchronisation mechanism for IPC under Windows OS.
45. What is a device driver? Explain its role in the OS context.
46. Explain the architecture of device drivers. .
47. Explain the different functional and non-functional requirements that needs to be evaluated in the selection of an
RTOS.

I.
.,'' ' , .. 6f:a
,·'< .'buffer:holdirig
'"' ._,'
:t:~if·iii~~:•·
,,tr}~ir:!\1~;::£:~t~f~;~~::1,1;:p~§i~'..
., the. data}::O~tfa
. . .-<'~"'· ,,.,,,,. .. ,.,.,.,,_> --,:}~';, ..":«-\,~:i '.:''
,.(b) ·, The mainthread
·
sleepsJor
.., -,;;· .. · ,
ap i'~¢qph~jfff't;~f
, ,·'· "<~.::•-"•:""t,,.,~.,,.~Y~:~:::-/'.(.,·.:&~,i:\1
.. ( c) ,,The child thread retrfov~s tpe n1e§s,~g<r;fro _,_ .
. ,the retneved daJ~ tcdhe cbnsole rula~l~epsf
{d) :Use appt6priate: er:r;r•ll~ndfing ni~<Sli~~irisif<• ,
2: Write a mtiltithreaded Win32 cpnsole applit#ioft;';f(j
,Each thread prints the message:'I'.minJhrdtd;tht~lf•
,ds created. Ifvarie8- f:wni g){ry;;JY~ri~1?,ii~~ltri1~e:,,,
the dhildJhreads, wait for the bClmpl~ti()P..oLfhe,~J(:¢¢.
arecompl~ted thei~ ~xecutio~. ·· ..,. · ·' ':'"'-•'''< ~\;
3. Writy,a,1:v:~ilHthr,~a,sle,£&PB\~C~!\On;µsitig ;f'.f!g~M-i}:lq}.!fti _,·. , ' _. . _ :<
The application should receive 'n' as command line.p'.aq1m~1frf/§1!,,<\/,:;'•~lL.~~H,to .,, , , ~eA,\~;;1nJ.;~~d
t!iread no" ('t~ea1.n()' is _the n}lmber pa,sse,d t()Jll~ t~e,~9;W~~~~it1i,~4<2J,~~taij§J\:Y~~~;~,;..9,!!{h1:!91i~,faitl~BH'.f\~tsPs ;
for 1 second and then quits.
..
The '
main thryaµ,
,•;
after:cr~atiµg;tlj;ej~limhtlv~fl~S,V:~di#:for.:.,tqe,:c9ij:ipJ~!ict1;(9f;t,lle,;~x:~
.••••-. '.' "_ ,,;,~.. ;~•'-'•~<\;•(~:C,,'.'.(?~t./\.~,:~:.;•/;%;::.f'.;'.'~\'v••,;,::,'",<"(•;, ".,.•f." }J: ~'{<~.o/¼°.''•</1\:M","••;_.-..,~•;->;.:',i''""("\_>:'.:•.•;,, i
0
ecution _of child threa'ds _and quits w,hen all the cl:plq,threagia,r~;c,qµi:pl~tecli:t,4¢)1' ~iecutip11,\{;,◊fuP1l~!11J.if~xecute
the application in Linux. _, . .. . , "i;:)J1:'{i' ., . : ,., "i:•: :- '. , .• ·"!•: • . ' . . •"'•· . : .
4. Write a multithreaded applicatipn in Win3,2 satisfying tbf1£qJf9-¼,m~::: . I
(a) Two child threads.are cre1;1ted withnormaJ priotjt)L, 3;i\,,,;:,r·. ·. . ·.
, •• , .,)." N >'-, ,., ,>'~-..,.,_• ;; ,{ '. , ,~ 0'

(b) Thread 1 retrieves and prints its priority and sleeps for=,19Q 1Jlilliseconds and tlien,,qu,its ,
(c) Thread 2 prints the priority of thread 1 and raises its ptjqrit£'t9 apoye tioi;maLa11d retrieves th,e
fthr_.e_ad l_,_prints 1·tandth,enqu1·ts. , :c-,,·,,,.. •;--·:· ....... : ,,, , -,.·, .,. . , ... · · · ·,
pe~ priority
· .. ·
O ,":'.v'<'"-,_•~ ~,~_,,~Ji'>,~~,/ t,«.!'

(d) The main thread waits for the completion 9f b9th tiie,9hill!,thl~ii"4s th;~:t~nnitiat~s, , . , ,' . : , : • ,iii~

c::;;:~i~~:p:c::;~~:~~~;;r;ff~!i(4~~1;!1~iff~'
5. Write a Win32 conso~e application illustra,ting:the,µs~g~•~f@{B~w:~~iii'i~¢{Jo?\iat{~li.ipni~~twd,iii)1 p~rivt

~:~
(b) The main thread creates an event object "synchronise'?:Wt)~, ~te.µRn~§'igna,U~o.~ti9a'thilq,)µ'n!ad:witl111aµie
'child_thread'.. · : •'J\1riri~:~11 ~ ;i~~i~t,}r~;::'.,;';:,+fi/;;;,ij)'I:}:'.f :~.:[: :.,::·;r.: ) .,. .,:
(c) The main thread waits for the signalling Qf the e:v~~HR~iY:9,tfM~8~9~f?.'.~. ~~J,e~fis. :#~Ja frqfu:;Qie an9py-
mous pipe when the event is signalled and prints the,g~§i:;~~# 11'.Qµ\th.~;~ipe,pqjµe ¢.pn&'ol~:W;inp9w, ,•._

l
 Real-Time Operating System (RTOS) based Embedded System Design

(d) The main thread waits for the execution completion of the child thread and quits when the child threacl.
. completes its execution. . . .. .. . .
.·. ; · le):·rliechil{:fiiread fuitettqe data ''H(fr~ill cpild
,tl}ie3:d'')to 1he anohyni~us pipe and si::ts the ·event object

~t~1t:,~f~~;~;:a~2t~~ttf
·· · rite ·
;f·l111;f1!~i;j~½~~;ri;1;\t~;~;ah~~t~ffer6{
··
··
No,n{P_roqessJ}illqstf!lfin:g,th : · · · · ·
·, ·•.
'"'"=·.)r.: . ·
;Q(~.~tl;~11~.~yertiW,.Y''
·e1i'tli(hivent itsigria aiitl displa ea e~
a second console applicatiqn (Process 2) for. opening the memory mapped object with narne,."mysharedobjecf!
and event object with name "synchronise". Write the message ''Message from Prosess 2" tqtlie memory n1appecl .·
object and set the event obje,ct "synchronise". Use appropriate.eqpr handling :mychanisms wllerever possible.-
Compile both the apJ>lkation~ ustn.g Visual Studio and execute themjn the order Process 1 followed by Probesf
2 under Windows XP/NT OS. ·· ·
7. Write a multithreaded Win32 conso1e application where:
(ii) ·\Tne:fuainthfead'creites a child thread with default stack size and 11ame 'Child Thread'.
(b) The'1miin tlireai:I seticls user defined messages and the message ,'WM_QUIT' r~domly to the child thread.
(c) The child thread processes the message posted by the main thread and quits when it receives the 'WM_:_
QUIT' message.
(d) The main: thread checks the termination of the <;bild thread and quits when ,the,chiltl thr~d completedts
execution.
(e) The main thread continues sending rando111messagesto tht(childthread till the WM_,_QUIT message s~nt is
to cl::lild thread.
(f) The messaging mechanism between the main thread and child thread_is synchronous .
. Compile the application using Visual Studio'aqd, ex~cuteit under Windows XP/NT-QSc
8. Write a Win32 console application illustrating the usage of anonymous pipes for data sharing between a parent
and child processes usingpandle inheritance mech~ism. Compile and execute the {lpplication using Visual.Stu~
dio under Windows XP/NT OS.
9. ,Write a Win32 console application for creating an anonymous pipe with 512 bytes of size and pass the 'Read
handle' of the pipe to a second process (another Win32 console application) using a memory mapped object. The
first process writes a message "Hi from Pipe Server". The second process reads the data written by the pipe server
to the pipe and displays it on the console window. Use event object for indicating the availability of data on the
pipe and mutex objects for synchronising the access to the pipe.
10. Write a multithreaded Win32 Process addressing:
(a) The main thread of the process creates an unnamed memory mapped object with size lK and shares the
handle of the memory mapped object with other threads of the process
(b) The main thread writes the message "Hi from main thread" and infonns the availability of data to the child
thread by signalling an event object
(c) The main thread waits for the execution completion of the child thread after writing the message to the
memory mapped area and quits when the child thread completes its execution
(d) The child thread reads the data from the memory mapped area and prints it on the console window wherithe
event object is signalled by the main thread
I (c) The read write access to the memory mapped area is synchronised using a mutex object
11. Write a multithreaded application using Java thread library satisfying:

I
(a) The first thread prints "Hello I'm going to the wait queue" and enters wait state by invoking the wait
method.
(b) The second thread sleeps for 500 milliseconds and then prints "Hello I'm to invoke first thread" and
invokes the first thread.
(c) The first thread prints ''Hello I'm invoked by the second thread" when invoked by the second thread.
 con
exe
egy
Let
Sys

vx·
wv.i
SIOJ
(PP
of1
' LEARNING OBJECTIVES
COI1
Tin
plic
tior

a ':
sch
sag

11
Un
S"i:ast· tim
.f ·1i.~atn a :,~[!3~)1; RE
✓ Learn ahou( 1C(0.1/Q~11I'kJf~ef'.servites and initialls~tidn, > ...•.• ·.•· PE
✓ Learn about fosJ{icheduling'uider MicroClOS~II k!{triet· \. ... •. <':~[{~·
✓ Learn about inter-task'comm~nicdpo1 mecbanisrr~. sppported by !'4ictof:OS DE
✓ Learn about the frisk co111ijiunYcation pnd synthroqisation un1,~r Mic. SU
✓ Learn about timing anti reference ;fmpleinentation by MicroC/0 det
· operations · ·. ·· · ·

l
tio1
✓ Learn the dynamic memory management under MicroC/0S-II kernel
the
✓ Learn· about the interrupt hahdling meclianism·and implementation ofintetrupt'Sefviq~j;Rciftftjes
1

'Sl
OS-II kernel . . ·.·· ·.· ..... {'< ... ,1 { ll
✓ Learn about the Integrated Development Environment for 05 customisation ancf:;appliE,qponidefJtqjifn~rl.ti/.or l

·MicroC/05-II ·i SUS
er 1
t pn1
In Chapter IO we discussed about the fundamentals of RTOS, the different kernel services of an em
CUI
RTOS, the different techniques used for implementing multitasking, the different mechanisms use(\ for
. \
un1
an
tas.
j
;i
i
 An Introduction tc.iEmbedded System Design with VxWorks and MicroClOS-11 RTOS

communicating between multiple concurrently running tasks and the mechanisms to synchronise the
execution of tasks and accessing of shared resources. The implementation of the multitasking strat-
egy, inter-task communication and synchronisation is OS kernel dependent. It varies across kernels.
Let's have a look at these implementations for the VxWorks and MicroC/OS-11 Real Time Operating
Systems.

VxWorks is a popular hard real-time, multitasking operating system from Wind River Systems (http://
www.windriver.com[). It is fully compatible with the POSIX Standard (1003.lb) for real-time exten-
sion. It supports a variety of target processors/controllers including Intel x-86, ARM, MIPS, Power PC
(PPC) and 68K. Please refer to the Wind Driver System's VxWorks documentation for the complete list
of processors supported.
The kernel of VxWorks is popularly known as wind. The latest release of VxWorks introduces the
concept of Symmetric multiprocessing (SMP) and thereby facilitates multicore processor based Real
Time System design. The presence ofVxWorks RTOS platform spans across aerospace and defence ap-
plications to robotics and industrial applications, networking and consumer electronics, and car naviga-
tion and telematics systems.
VxWorks follows the task based execution model. Under VxWorks kernel, it is possible to run even
a 'subroutine' as separate task with own context and stack. The 'wind' kernel uses the priority based
scheduling policy for tasks. The inter-task communication among the tasks is implemented using mes-
sage queues, sockets, pipes and signals, and task synchronisation is achieved through semaJJhores.

11. 1. 1 Task Creation and Management

Under VxWorks kernel, the tasks may be in one of the following primary states or a specific combina-
tion of it at any given point of time.
READY: The task is 'Ready' for execution and is waiting for its tum to get the CPU
PEND: The task is in the blocked (pended) state waiting for some resources
DELAY: The task is sleeping

1 SUSPEND: The task is unavailable for execution. This state is primarily used for halting a task for

I debugging. Suspending a task prevents it only from the execution and will not block it from state transi-
tion. It is possible for a suspended task to change the task state (For example, if a task is suspended when

l
the task is in the state 'DELAY', sleeping for a specified duration, its state will change to 'READY'
'SUSPEND' when the sleeping delay is over.
A task may run to completion from its inception ('READY') state or it may get pended or delayed or
suspended during its execution. If a task is picked up for execution by the scheduler, and suppose anoth-
er task ofhigher priority becomes 'READY' for execution, and if the schedµling policy is pre-emptive
is
priority based, the currently executing task is pre-empted and the high priority task executed. The pre-
empted task enters the 'READY' state. If a currently executing task requires a shared resource, which is
currently held by another task, the currently executing task is preempted and it enters the 'PEND' state
until the resource is released by the task holding it. If a task contains sleeping requirement like polling
an external device at a periodic interval or sampling data from the external world at a periodic time, the
task sfoeps·~uring the periodic interval. The task is said to be in the 'DELAY' state during this time. If
 Introduction to Embedded Systems

a debug request for debugging a task in execution or if an exception happens during the execution of a
task, it is moved to the state 'SUSPEND'.
When a task is created with the task creation kernel system call tasklnitO, the task is created with the
state 'SUSPEND'. In order to run the newly created task, it should be brought to the 'READY' state. It
is achieved by activating the task with the system call taskActivate(). The system call taskSpawn() can
be used for creating a task with 'READY' state. The taskSpawn() call follows the syntax
. taskSpawn .(t~sk 11ame, task. priority, task options, . task stac):(<!3ite, rouf.irre .·
'n~me, argl, ~·r_g2, arg3, arg4', arg5, ;~rg6, 'arg7, arg8, a~glO"); •· ····· ··- arqf
where task_name is the name of the task and it is unique. The parameter task_priority defines the prior-
ity for the task. It can vary from O (Highest priority) to 255. The task_options parameter specifies the
options for the task. For example, if the task requires any floating point operation, it should be set as
VX_FP_TASK. Set the option ·as VX_UNBREAKABLE for disabling breakpoints in the task. Refer to
VxWorks' documentation for more details on the task options. The parameter routine name specifies
the entry point for the task. It can be function main ~ir a subroutine. 'arg l' to 'arg l O' specifies the argu-
ments required for executing the task. It is possible to have multiple tasks with the same routine_name
and different argument list. Each task will have its own stack and context. On creating the task, task-
Spawn returns a task ID which is a 4 byte handle to the task's data structure. The following table gives
a snapshot of various task creation and management routines supported by VxWorks.

tasklsSuspended() a
Check whether taskis in the 'Suspend' sate
tr ,,o 1
>Jpe(f!l~t~·~e~
taskRegsGet() Get th~ re.gisterdetails of a task
cas!R,egsSet() ~~t tl,ifi:e2i~FJE§/orayi~k,~ .·
tasklnfoGet() Retrieve information about the task
taikTcbt) · · '1 • ~:~!i-i~~e;fp&iiit~f,o: thSia§k's Ti~k ~\lntf~fB16cf
task!dListGet()
,, ,,
Retrieve the1ist of all 'Active' tasks.
.,.,., >.,·,r:<'0c·
taskSuspend() · · ,s4spe~c1JtisitJcii~ngi· :"i~u§fh@:) ·. ·~ ·
taskResume() Resume a task (Change state to 'READY')

t Please refer to the VxWorks lior:iry reference manual for the parameter details of each function call.
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-II RTOS

•,:Iii;i';ii\; ~~~~pitt, •. ;~sR>irdticr¢i~~t>~il<.rn~iBti~i~~)§[9~~~p~f~,:fl!tfi~;,

.'':': j:SJe, · · tinier tick umts). The stafe of,
·.-- : :.'_--, -·,·-·• "· - : r\ . 'i·. , ,-, -,, :.;.- _· · . ·- ''i:.·~ '.. ·,c;_

The task creation and management system routines are part of the library taskLib. The following
piece of code illustrates the creation of task.
/,/Heade;r .for Vx.yvo.rks kernel ,sp:ecific. implementations
, #1,i11c;l Gqe :"yxWor.ts .. h'(
j/d,nclude .''taskLib..h"
#fnclude "stdio.h"

/ /Function Prototype
v6idprint_task(\loid);

I/***~************·***·******·**'**** *·*15.*~* *** ** * * * ** * **·+.:* * * *.* ** * * *** * *

//Main task

void main task(void)

int tasked;

//Spawn Task A
if((taskid = taskSpawn("taskl",90,VX_NO STACK FILL,2000,
(FUNCPTR) print_task,0,0,0,0,0,0,0,0,0,0)) ==. ERROR)
I printf ("Creation of print task failed\n");
exit(); •

l
•
)

//*******************************************************************
//Task print task

void print task (void)

{
int ID;
//Get the task ID
ID= taskidSelf( );
//Print the task ID
 Introduction to Embedded Systems

tim
pm
IS C
ing
,
The main task main_task creates a new task with name task], priority 90, stack size 2000 and option exc
NO_STACK_FILL and terminates. The new task task] retrieves its task ID, prints it and finally deletes tiot
the task. · con

11.1.2 Task Scheduling 11

On the scheduling front, VxWorks supports two types of scheduling interfaces, namely 'POSIX sched- Tht
uling' and 'wind' scheduling interfaces ..The 'POSIX scheduling' interface is based on the concept of tasl
'process' and it defines~ portable interface, whereas the 'wind scheduling' is based on the concept of tasl
'tasks'. The POSIX standard for task scheduling allows setting the scheduling policies independently fol)
for process (i.e. It is possible to set the scheduling policy of a process as 'Round Robin', whereas for
another process it can be 'Priority-based' scheduling, provided the scheduler have tlie implementation
for both). But the VxWorks' implementation of POSIX scheduling interface does not allow the setting
·of different scheduling policies for different tasks. It allows only a single system wide scheduling policy
for the different tasks running on it. The table given below gives a snapshot of various POSIX schedul- tas1
ing calls supported by VxWorks. sat;
nel
cep
of~
or c
ren
Vx'
ker

11
Tht
Rer
. ace

VxWorks supports two different types of.scheduling policies namely; Round Robin (Time slice
based) and Priority based pre-emptive. The Round Robin scheduling policy is adopted for priority reso-
lution among equal priority tasks. Imagine a situation where more than one tasks with equal priority are
in the 'READY' state and the currently executing task is also with the same priority,if the scheduling
policy adopted is pre-emptive, these tasks may not be able to pre-empt the currently runningtasks since
l glo1

que
twe
for
they are of equal priority. The other tasks will get a chance to execute only when the running task volun- vie(
tarily relinquishes the CPU or it is pended on a resource request. This issue can be. addressed if Round Wo
Robin policy is adopted for resolving the priority among equal priority tasks. Round Robin scheduling Tht
can be enabled with the function call kerne!TimeSliceO. This function takes the time slice in the form of me:

t Please refer to the VxWorks library reference manual for the parameter details of each function call.
 An Introduction to Embedded System Design with VxWorks and MicroCIOS-11 RTOS

timer tick. Each task is executed for the amount of time specified, if there are ~ultiple tasks with equal
priority exist. The task relinquishes the CPU to the other task with equal priority when this time intetval
is completed. Setting a time interval value of Ofor the time slice interval disables Round Robin schedul-
ing for equal priority tasks.
VxWorks kernel has a well-defined exception handling module which takes'~are of tµe handling of
exceptions that arises during the execution of a task. In case of an exception, the task caused the excep-
tion is suspended and the state of the task at the. point of exception is saved~· AU other tasks and kernel
continue their operation without any interruption.

11.1.3 Kernel Services

The kernel fun~tionalities of VxWorks is i:tlso implemented ;s tasks an:d they are known as system
tasks. The system tasks exist concurrently with user defined tasks. The root task tUsrRoot is the first
task executed by the scheduler. The function usrRootO is the entry point to this task and it performs the
following:
• Spawns the logging task tLogTask, the exception task tExcTask, the network task tNetTask, the tar-
get agent task tWdbTask and tasks for optional components (like shell service tShell, Remote login
tRlogind, etc.) selected by the user while building the kernel.
The Root task is user customisable and user can add necessary additional initialisation code to this
task during the kernel build time. The root task's responsibility gets over with the starting of all neces-
sary initialisations and it is terminated and deleted after the initialisation process is completed. The ker-
nel modules use the logging task for logging system messages without current task context IO. The ex-
.. ception handling task is responsible for handling the exceptions/errors encountered during the execution
of a task. It has the highest priority. The priority of it should not be altered in any form by suspending
or deleting the task or by assigning a lower priority. The tRlogind daemon is responsible for managing
remote login request from another VxWorks target or a host machine. For this functionality to work the
VxWorks' target shell tShell and the remote login service components rlogin should be'included in the
kernel build configuration ..

11.1.4 Inter-Task Communication

The inter-task communication is facilitated through shared memory, message queues, pipes, sockets,
Remote Procedure Call (RPC) and signals. Mutual exclusion and synchronisation in shared resource
·•1_· access is implemented through semaphores.
_ •

VxWorks kernel follows a single linear address space for tasks. The data can be shared in the form of
·global variable, linear buffer, linked list and ring buffer.
·1 'Message queue' is 1 the primary inter-task communication mechanism under VxWorks. Message
.- queues support two-way communication of messages of variable length. The two-way messaging be-
\ tween tasks can be implemented using one message queue for incoming messages and another one
for outgoing messages. Messaging mechanism can be used for task-to task and task to Interrupt Ser-
vi~e Routine (ISR) communication. Two different versions of message queues are supported by Vx-
.Works. They are; POSIX based ·message queues and Wind driver kernel ( wind) specific message queues.
The table given below gives a snapshot of various' Wind message queue based function calls for
messaging.
 Introduction to Embedded Systems .

. .
It is not necessary that a message queue always have space to accommodate a message when a task
tries to write a message to it. The message queue may be full and may not have room for accommodat-
ing a message. In such case the task
' . can either wait until a space available in the queue or can return
immediately. Similarly when a task tries to read a message from the message queue, there may be situa-
tions in which the message queue is empty. The task needs to wait until a message is available or it·can
return immediately. The choice on whether the task needs to wait or return immediately is determined
by the timeout parameters used in conjunction with message sending and reception. A time out value
NO_WAIT (0), allows the task to return immediately and the value WAIT_FOREVER (-I) forces the task
to wait until a space is available for posting a message in the case of message sending and a message is
available for reading in the case of message reception.
A message_2~n be posted as either normal message or high priority (urgent) message. The msgQSend0
function provides options to set a message as either normal or high priority. A normal message is placed
at the bottom of the message queue and a high priority message is always placed at the top of the mes-
sage queue. A value MSG__PR!_NORMAL for the message priority option declares it as normal message
whereas the value MSG_PR!_ URGENT sets a message as urgent.
The following piece of code illustrates the implementation of Wind message queue based communi-
cation in a multitasking application.

Here a main task creates two tasks, namely, 'task_a' and 'task_b' with priority 100, stack size 10000 and option NO_
STACK_FILL. It also creates a message queue with number of messages supported as 50 and the maximum length in
bytes for a message as 20. The message queue is created with an option for queuing the pended tasks (tasks waiting for
a message to arrive in the message queue) as FIFO. 'task_a' sends the message "Hi from Task A" with message priority
'urgent' and with option for waiting ifthere is no space available in the message queue for posting the message. 'task_b'
receives the message from the message queue and waits for the availability of a message if the message queue is empty.
I
I /Header· for VxWorks kernel specific implementatioris
.#in,cludE:: . ~'v;x,Works ,,h 11
J//ll-l;eader for Wind task related functions
finclfide ~taskLib.h"

t Please refer to the VxWorks library reference manual for the parameter details of each function call.
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-II RTOS

#include "stdio.h"
//Header for Wind Message queue related functions
#include "msgQLib.h"

#define MAX_MESSAGES (50)

#define MAX MESSAGE LENGTH (20)
#define MESSAGE "Hi From Task A"

MSG_Q__}D MsgQu~ueID;

I I***********************·**********··* ************************
//Task A

void task_A(void)

//Send message to message queue

if ( (msgQSend (MsgQueueID, MESSAGE, MAX MESSAGE_:LENGTH, WAIT_FOREVER,
MSG_ PRI _ URGENT) ) == ERROR)
printf ( "Message Sendtng failed .. \ri"'J;

//*******************************************************************
//Task B

void task_B(void)

char msgBuf[MAX_MESSAGE_LENGTH];

//Receive message from message queue

if(msgQReceive(mesgQueueid,msgBuf,MAX MESSAGE LENGTH, WAIT_FOREVER)
== ERROR)
printf ("Message reception failed ... \n");
else
printf("Message Received from Queue: 9as\n",msgBuf);

I //*******************************************************~***********

I
1
//Main task for creating the message queue and creating tasks A & B
r
y void main task(void)
~

int taskld;

-fl Create message queue

if ( (mesgQueueid msgQCreate(MAX MESSAGES,MAX_MESSAGE LENGTH,MSG_Q_FIFO))
== NULL)
printf ("Message Queue creation failed ... \n");
 Introduction to Embedded Systems

//Spawn Task A
if((taskid = taskSpawn("task_a",100,VX_NO_STACK_FILL,10000,
(FUNCPTR)task_A,0,0,0,0,0,0,0,0,0,0)) == ERROR)
printf("Creation of Task A failed\nn);

//Spawn Task B
· if ( (taskid taskSpawn ("task_b", 100, VX NO_STACK_FILL, 10000,
(FUNCPTR)task_B,0,0,0,0,0,0,0,0,0,0)) == ERROR)
printf("Creation of Task B failed\n");
}

The POSIX standard supports named message queues with options for setting message level priori-
ties. The table given below summarises the list of POSIX Message queue function calls supported by
VxWorks.

~!i~1J~v~,~\i:s~u::o ...;,:;·. :-ltj9{~,!,y;}ft~t~f;:i;;,i&i\;-';ifii1~}}lii

~mqPrl;tbi~it() . ·e~.tluz PO~~'ro}~ss,~gt'·libra'',·;fhe:1~itiali~at
,,: ' ' .· ·,. 't>:-i-•:''. ''';•:·''!: ._;., ":~· .. ~.··,•. .

•,·:~iiJ~,s a,~6~~~.~;tdtBf:ciu~te::i~?·o~tiiii'~~!q~)'Bfi¢{~PtSi~~~I
·,'ift~em .ts .119. r~gtnl~ftO't'Ot}l ~~?~~ge' ·~plas~. infhe••tpes~ag~.f!Ueutr ·
, w~it until. tli6rejs'~p~c~ (or ~~1nkthe myssage in.1.li~ mes~ag~ qb"etie:c
. . JVifhdifferentprioriti~};."The pf;Qrity rapge~,;fr~rji 0Jlq»'.estftb3'l (~iih~#ll~i§ri,
.,, priority mess.age is always placed infroµtgfth~ messa'g~ querif '
• ' C ' ' • ' • > ",;' 0 > \•
·•
,.,; - \\ < ,_{ • '•' ;., • ~., •• , '

mq_close() Used by a task to indicate it is not using the message queue anymore.
mf_uh[i~k()
, ~ ,· ,>;--- · ·.us~d py1a,~~~fo ~.~.stfRY~;~~/s~&~4~~1{~:'l{n\ 1
•• : •· •i~stf~;~ei~~f~A~f ~eu/~
task~ wp.ich are .using,~e ·q~e11~ cl~se it:'.;;: •' · ' tr;'. .r«• ..:: .: -; " · · ·
mq_notify() Notifies a task, when a message for the task arrives in an empty message queue. The mq_notifyO
call specifies a signal to be sent to the task when a message is placed in an empty queue. A task
can cancel the notification registration at any point during the waiting by passing a NULL in
place of the signal value to the mq_notifyO function call.
mq_setattr() Sets the attribµtes for !}le message queue. The attributes are:
1. Blocki11g flag Q_NONBLOCK.
· 2. Allptf<l m~tyium nupil;i,~t of messages ll1 the queue. I
3. A,IJ.pwed,rp~im~.s_ii,e dfa m,~ssi~t\ .
4.. The nuinber of messages currentlypresen(in the queue.
A tiisktan'thange only the blo~kmg flag.
mq_getattr() Retrieves the attributes for the message queue.

t Plea~e refer to tl,e VxWorb l1'irnr'.) reference manual for the parameter Jcta;ls of each function call
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-II RTOS

Pipes are another form of IPC mechanism supported by VxWorks. Pipes use the message queue
based technique for communication. The only difference is that pipe acts as a virtual I/0 device and it
can be accessed with I/0 access calls in the same way as accessing an I/0 device. The syntax for pipe
creation function is given below.

where the first parameter is the name of the pipe, the parameter max_msgs represents the maximum
number of messages and the allowed m.aximum size of a message. Normal Input/ Output routines like
open, read, write and I/0 controls an~ used for accessing pipes. Interrupt Service Routines are only
allowed to write to a pipe and not reading from the pipe.
Sockets are the mechanism utilised by Vx·Works to communicate between processes running on different
targets which are networked and for executing a procedure (function) which is part of another process
running on the same CPU or on a different CPU within tlie network (Remote Procedure Call (RPC)).
Sockets works on Internet communication protocols. VxWorks supports TCP/IP and UDP based proto-
cols for socket communication.
'Signals' is a form of software event notification based Inter Process Communication (IPC) mecha-
nism supported by VxWorks. The 'signal' mechanism of VxWorks supports 31 different signals. A
signal is associated with an event and the occurrence of the event asserts the signal. Any task or Inter-
rupt Service Routine (ISR) can generate a signal which is intended for a task. Upon receiving the signal
notification, the task is suspended and it executes the 'signal handler' associated with the signal on its
next scheduling. As a rule of thumb the signal handler should not contain any routines which contain
code (e.g. Accessing a shared resource, critical section, etc.) that may cause the blocking of the task and
thereby leading to a deadlock situation. 'Signal' based IPC mechanism is more appropriate for exception
and error handling than general ·purpose communication mechanism. The definition for a typical signal
handler is given below.
;,\foid<~sigHandler '(int sigNum)

where sigHandler is the name of the signal handler function and sigNum is the signal number.
The definition for a signal handler for passing additional arguments will look like
void sigHandler (int sigNupi, int code, struct sigcontext *pSigContext)

where sigHandler is the name of the signal handler function, sigNum is the signal number, code is the
additional argument and pSigContext is the context of task before signal.
The Signal handler function should be attached to the signal using the function sigaction() (For
POSJ:X compliant signal usage) or sigvec() for Wind signal usage.
VxWorks support two kinds of 'signal' interfaces, namely;
1. UNIX BSD Style Signals
2. POSIX Compatible Signals
The table given below summarises the list of basic 'Signal' function calls supported by VxWorks.

~!L~i~~;~i!ll::<1:'':if]~'.,:l.' , . %~~:::!:{\,::} :::,:L'!.~~~~;~f ~'.':£t:i£:~~iti)\~~::1:t

''~fliiitc}. . ; S~a.(H~~1pit1ali~ati<;m routine. It must be executed duri9:g the 0~ initialisation before
· ·'· enabliIIgJntern.ipts.:
• , ~,.,.. ,."'"""---•-·"'·'"'"·'s,,\.t:;,<, ·._ .. _. ·,
·

t Please refer to the VxWorks library reference manual for the parameter details of each function call.
 Introduction to Embedded Systems

11.1.5 Task Synchronisation and Mutual Exclusion

Data sharing is one of the inter-task communication mechanism adopted by VxWorks. VxWorks fol-
lows a single linear address space for all user tasks. Imagine a situation where a global variable is being
accessed by a task and it is pre-empted by a high priority task (or by an ISR) and the high priority task
(or ISR) also tries to modify the global variable. It may result in inconsistent result, if the operation on
the global variable is not atomic. Hence it is advised to give exclusive access to a shared resource when
it is being used by a task. In other words make the access to shared resources mutually exclusive. It is
essential for task synchronisation. VxWorks implements mutual exclusion policies in three different
ways. They are
1. Task Locking (Disabling task preemption)
2. Disabling interrupts
3. Locking resource with semaphores
Task locking (Disabling of task preemption) provides restrictive access to shared resQurces. The
function call taskLock prevents the kernel from pre-empting the task. However it will not prevent the
execution of Interrupt Service Routines (ISRs ).' This method is suited when there is no global data
shared between tasks and ISR. Otherwise the problem will be in the half solved state. The major draw-
back of this approach is the deviation from real-time behaviour. With task preemption disabled, a high
priority task may not be serviced until the currently running task relinquishes the CPU by enabling the
pre-emption (By calling taskUnlock). It is not an acceptable behaviour if the high priority task doesn't
involve accessing of shared resource which is held by-th~ currently ex.ecuting task. An overview of the
implementation of task locking based mutual exclusion is given below.
#include "vxWorks.h"
//**********************************~**~*********************~*******
//Task_A

void task_A(void)
{
I/ ........ .
I/ ........ .
//Disable task preemption
taskLock ();
//Shared data acc6ss code
I/ ........... .
//EnabLe task preemption
taskUnlock();
. }
 An Introduction to Embedded System Design with VxWorks and MicroCIOS-11 RTOS

Interrupt locking based mutual exclusion implementation disables interrupts. It is appropriate for
exclusive access of resource shared between tasks and Interrupt Service Routine (ISR). The major draw-
back of this method is that the system will not respond to interrupts when the task is executing the criti-
cal section code (Accessing shared resource). It is not acceptable for a real time system.
An overview of the implementation of interrupt locking based mutual exclusion is given below.

It should be noted that the implementation of the intLock routine is processor architecture dependent.
The intLock routine returns an architecture-dependent lock.,out key representing the interrupt level prior
to the call. For example, for ARM processors, interrupts (IRQs) are disabled by setting the 'I' bit in the
CPSR.
Semaphores provide both exclusive access to shared resource and synchronisation among tasks. Vx-
Works has the implementation for Wind specific and POSIX compliant versions of semaphores. The
Wind specific:sefuaphores supported by VxWorks are:
1. Binary semaphore
2. Mutual exclusion semaphore
3. Counting semaphore
The binary semaphore provides exclusive access to resource by locking it exclusively. At any given
point of time ~~e state of the binary semaphore is either 'available' or 'unavailable'. Counting sema-
phore is used for sharing resources among a fixed number of tasks. It associates a count with it and the
count is decremented each time when a resource acquires it. When the count reaches 'O' the semaphore
will not be available and a task requesting the semaphore is pended. The count associated with a count-
ing semaphore is specified at the time of creating the counting semaphore. Counting semaphores are
usually used for protecting multiple copies of resources. On releasing the semaphore by a task, the count
associated with it is incremented by one. The inherent problem with binary semaphore is that they are
not deletion safety, meaning whenever a task holding the semaphore is deleted, the semaphore is not
released. Also the 'binary' semaphore doesn't support a mechanism for priority inheritance for avoiding
priority inversion. These limitations are addressed in a special implementation of 'binary' semaphore
called 'mutual exclusion' semaphore.
The semaphores are distinguished with the way they created. The access and control routines for all
semaphores remain the same. The following table gives a snapshot of the different semaphore related
function calls.
 Introduction to Embedded Systems

.~~ ... ·1·.. o···.·.i,,.'

r ··U•.•.'.iilc·,.·.·t:
'.'.!tr·.··
.•.· •.
. u..·•.v .•..•.•a·'.·. .ll. t. :.c.·.1.: . '·n··. . .,.·. ' •, 111. r'. z. t~•l
·~t,.,.~~s~~!i!t . .
S;(ni~itaied . .. .·...
I,;; C J . ••

<'nd initialise a . macy se . .· .

'ed, as ,the .se,!Ilit,pho
"apu9te, 1~1fte i~ . . . .. s
.•• ; • ,.::\
'or :pri
thet'"itrFIFo irto~eISEM~Q
,;:.; .• $

''''.,",' >:

The mutual exclusion semaphore has an option to set its priority to the highest priority of the task
which is being pended while attempting to acquire a semaphore which is already in use by a low priority
task. This ensures that the low priority task which is currently holding the semaphore, when a high prior-
ity task is waiting for it, is not pre-empted by a medium priority task. This is the mechanism supported
. by the mutual exclusion semaphore to prevent priority inversion. To make use of this fe~re, the mutual
exclusion semaphore should be created with the option SEM_INVERSION_SAFE and the queue holding
the pended tasks waiting for the semaphore should be sorted on priority basis. These two options should
be specified while creating the semaphore. The syntax for this is given below.
Id semMCreate (SEM_Q_PRIORITY I SEM INVERSION SAFE);
where Id is the 4 byte ID returned by the system on creating the semaphore. It is used as the handle for
accessing the semaphore. The option SEM_Q_PRIORITY sets the ordering of the queue, holding the
pended tasks which are \.Vaiting for the semaphore, as priority based. The option SEM_INVERSION_
SAFE enables priority inheritance.
The mutual exclusion semaphore protects a task from deletion when it is currently in the critical sec-
tion. If the task is not protected from deletion when it is holding a semaphore and is executing in the
critical section, the semaphore will not be released properly and it may not be available for access to

t Please refer to th~ VxWorks library reference _manual for the parameter d~tails_of e::i.~h fig1gt_ion call.
 An Introduction to Embedded System Design with VxWorks and MicroCIOS-11 RTOS

other resources. This may lead to starvation and deadlock. In order to make a semaphore 'task deletion
safe', it should be created with the option SEM_DELETE_SAFE. The queue holding the pended tasks
waiting for the semaphore can be sorted on either priority basis or first come first served (FIFO) basis.
The task safe option should be specified while creating the semaphore. The syntax for this is given be-
low.
semMGreate. (SEM PRIORIIJ1Y'
0
1. SEM~DELETK

The semFlushO operation is illegal for mutual exclusion semaphores.

Whenever a task tries to acquire a semaphore and ifthe semaphore is not available (It is acquired
and being in use by other task(s)), the task enters the pended state and it waits for the semaphore in a
pended queue. The wind semaphores support a timeout mechanism to specify how long the task needs
to wait. It is useful for tasks which are not interested in wasting the time on waiting for the semaphore.
The timeout option can be set in the semTakeQ call used for accessing/acquiring the semaphore. Wind
supports three different timeout options. They are explained below.
Return immediately: If the semaphore is not available when the task tries to acquire it, the task returns
immediately and it will not enter the pended state. The return value in case of nonavailability of sema-
phore is S_objLib_OBJ_ UNAVAILABLE. The timeout option NO_ WAIT is used for specifying this.
Wait for a predefined time: If the semaphore is not available when the task tries to acquire it, the task is
_ pended and it waits in the pended queue for semaphores for the specified timeout duration. The timeout
is usually specified in terms of the 'kemeLtick'. If the semaphore is not available even after the specified
timeout duration, the task times out and ifreturns the value S_objLib_OBJ_TIMEOUT.
Wait Forever: If the semaphore is not available when tlie task tries to acquire it, the task is pended and
it waits in the pended queue for semaphores until it is available. The timeout option WAJT_FOREVER
is used for specifying this.
As mentioned earlier the pended queue holding the pended tasks waiting for the semaphore can be
ordered based on either priority or FIFO. It is specified by the option parameters SEM_Q_?RIORITY or
SEM_Q_FJFO respectively at the time of creating the semaphore. The priority based sorting enhances
the priority based execution with expense of kernel overhead. Whereas FIFO based mechanism is sim-
ple to implement and is free from overheads.
VxWorks also supports the implementation of PO SIX standard semaphores. PO SIX supports named
and um1amed semaphores and are counting semaphores. The interface for POSIX semaphores is defined
by the libra1y semPxLib.
I
11.1.6 Interrupt Handling

I VxWorks support a well-defined interrupt handling mechanism for handling hardware interrupts.
Efficient and fast handling of external interrupts is a key requirement for real-time systems. The salient
features ofVxWorks' interrupt handling mechanism are summarised below.
1. The Interrupt Service Routine (ISR) runs in a special context outside any task's context. This
eliminates the delay in context saving and context retrieval (Context switch delay) in contrast to
task execution. This greatly reduces interrupt latency.
2. A separate stack is maintained for use by all ISRs. It is allocated and initialised by the kernel at
the time of system startup. For processor architectures supporting this option, the same stack is
used by all ISRs. If the processor architecture doesn't support a single stack for all ISRs, the stack
 Introduction to Embedded Systems

of the task which is currently preempted by the ISR is used by ISR. In this case the stack size for
each task should be large enough to accommodate ISR stack requirement also. \
3. Supports connecting of 'C' function with system hardware interrupts which are not used by Vx-
Works kernel. The connecting of 'C function' with the interrupt vector is achieved through the
function call intConnectQ. It is responsible for saving the processor registers, setting up the stack
entry point, pushing the argument, to be passed to the ISR function, ·on the stack and invoking the
'C function' as ISR. The intConnectQ function takes the arguments; byte offset of the interrupt
· vector to connect to, the address of the 'C function' to be connected with the interrupt vector and
an argument to the 'C' function. The 'C function' becomes the ISR\for the interrupt. On comple-
tion of the ISR, the registers are restored to the original state. /
4. To avoid starvation and deadlock situations; as a rule of thumb, ISRs are not allowed invoking
routines (involving the access of shared resource protected through semaphores) that may block
the ISR.
5. ISRs are not allowed to acquire (take) a semaphore. But are allowed to release (give) a semaphore
(except mutual exclusion semaphore).
6. ISRs are not allowed to invoke memory allocation and de-allocation functions like mallocO, cal-
lo_cO,freeQ etc. The memory allocation functions internally make use of semaphores for synchro-
nisation and they may block the ISR.
7. ISRs are not allowed to call any creation or deletion routines. The creation and deletion calls may
use semaphores internally and it may block the ISR.
8. JSRs must not perform 1/0 operations through VxWorks drivers. The restriction is put for the rea-
son, most of the device drivers require a task context and it may block the ISR. However, ISRs are
allowed write operations for pipes, which is a virtual I/0 device.
9. ISR must not call routines/instrnctions involving floating point operations. The reason is that the
floating point registers are not saved and re-stored by the ISR connecting code. It is the responsi-
bility of the user to save and re-store floating point registers explicitly, if the· ISR involves floating
point calculation.
10. ISRs can make use of the logging service supplied by logger component to send text messages to
the system console.
11. If an exception happens during the execution of an ISR, wind stores the exception details and re-
sets the system. During the boot-up time, the boot ROM checks for captured exception messages
and displays it on the display console.
12. Interrupts communicate with tasks using shared memory, message queues, pipes, semaphore (can
give a semaphore but can't take one), pipes and signals.
13. The intLockQfunction performs a system wide lockout of all interrupts to the highest priority lev.el
supported by the kernel. If the intention is to lockout only interrupts up to a certain level and the
system wants to preserve the occmTence of high priority interrupts, it can be achieved through the
system call intLockLeve!SetQ, which sets the lock-out priority level to a desired one than locking
out all interrupts including high priority. With an intLockLeve!SetO, the intLockQfunction locks '
a
only interrupts with priority level specified by the lock level in intLockLevelSetQ. All other en-
abled, high priority interrupts are acknowledged. C

14. For interrupts whose priority is higher than that of the lock level set by the function intLockLevel~ f
SetQ and Non-maskable interrupts, the system call intVecSetO should be used for connecting a C t
function a.s ISR for the interrupt and also the ISR should not use any kernel facilities that depend t
on interrupt locks for their operation.
 An Introduction to Embedded System Design with VxWorks and MicroCIOS-II RTOS

The following table gives a snapshot of the Interrupt handling related function calls under
VxWorks.

(iritLqckLevdGetO
fL.. .'~'}if..iy~.....f/gt( )'. ...
1
g:i1r
<•.:;;L.
'.ifl_tVepSet(FUNCPTR * vect;,:; Th~:iJa~~ .
• It attaches an exdepti{m/µ~terrqpiltralh~difr fd:a spdcifi~<l°vJ:Ct~r.
function) is specified as an offset into the'CPU's vector table:lttakes anitiferrupt vector
as parameter, which·ls the byte offset into the·vector table and the address·•of
the 'C function' to be connected with the interrupt vector
..
intVecGet(F;UNCPTR * vector)
r,;/:~.. ·<
•'~e19p{\r~;" ¥tsf·tfi~~~~!;~: <> .i~[~:.~
" ,.. iBr•r;:" .
,, .-----:\. ·-~·
Yecfoi . . ctQ'r'is:fop,ecifir<;I / .... · .· · .· if . . or table.'
an 1ntemip_t_ve~tor ~§':pa{:atn~ter,whifh';1s' 'byti ~ffse1m.toth~ vector;t~biE:

11, l, 7 Watchdog for Task Execution Monitoring

Watchdog timers are essential for bringing the system out of 'system hang-up' condition. lf a task hangs
at some point of execution due to some unexpected situations (like the peripheral device is not respond-
mg while accessing it in an infinite loop), it should be brought out of the situation to make the system
operational. Watchdog timers are used for this. You can set a watchdog timer for the time expected
for the execution completion of the task or a portion of the task which is more prone to hang-up. Start
the watchdog timer when the task is started or when the task is executing in the suspected portion of
the code. If the execution of the task or portion of the task is not completed within the time set in the

i- Pka:,t.: 1dcr to Lhc V'-Works library reference manual for the parameter details of each function call.
 Introduction to Embedded Systems

watchdog timer, the watchdog expires and it raises a watchdog timeout event. The necessary actions to
t
handle the situation can be written in the watchdog timeout handler. Under VxWorks, watchdog timeout (
is handled as part of the system clock ISR. User can associate a 'C' function with the Watchdog timer.
s
The 'C' function is executed when the watchdog expires. The time.is specified in terms of system timer
e
tick. The timer is created using the function call wdCreateQ. The timer is started with the function call
wdStartO and it takes the number of ticks as timer value, 'C' furn;;tion to be executed in case of timeout
]
and the parameter to the 'C' function as parameters. The watchdog timer can be stopped and cancelled
at any time prior to its expiration by calling the function wdCancelO. l
The following table gives a snapshot of the watchdog timer related function calls.
I
le
fi
~~
F
tl

E
V
11.1.8 Timing and Reference n
In many of the scenarios the application may require timing reference. VxWorks provides access to the 0
sy-sf&!;n wide real-time clock for timing reference. Software timers and time reference can be generated
using these interfaces. For timer operations, the task can_ create a _timer and set it for the desired time. 11
The timer runs with the system timer tick and it generates the 'signal', SIGALRM when'it expires. The e:
task can associate a signal handler with this signal for performing the necessary operations in the event
of timer expire.
-~
11.1. 9 The VxWorks Development Environment
Tornado® II is the development environment from Wind River Systems for VxWorks 5.x development.
It includes the Tornado tools and the VxWorks run-time environment. The Tornado tools include the
Integrated Development Environment (IDE) for OS customisation and building. Debug interface for
debugging and simulator (VxSim) for simulating the target environment. Tornado® II development
environment is available for both Windows and UNIX development hosts. The Tornado (R) IDE is re-
placed by the Eclipse based IDE Wind River Workbench for Vx Works 6.x.

1L2 ·MicroC/QS-lI lS

MicroC/OS-II (µC/OS-II) is a simple, easy to use real-time kernel written in 'C' language for embedded nc
application development. MicroC OS 2 is the acronym for Micro Controller Operating System Version
2. The µC/OS-II features: si.
• Multitasking (Supports multi-threading) lS
• Priority based pre-emptive task scheduling Sl:
MicroC/OS-II is a commercial real-time kernet from Micrium Inc (www.micrium.com). The ca
MicroC/OS-II kernel .is available for different family of processors/controllers and supports proces- fo
sors/controllers ranging from 8bit to 64bit. ARM family of processors, Intel 8085/x86/805 l, Freescale

t Please refer to the VxWorks library reference manual for the parameter details of each function call.
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-11 RTOS

68K series and Altera Nios II are examples for some of the processors/controllers supported by MicroC/
OS-II. Please check the Micrium Inc website for complete details about the different family of proces-
sors/controllers for which the MicroC/OS-II kernel port is available. MicroC OS follows the task based
execution model. Each task is implemented as infinite loop.

11.2.1 Task Creation and Management

Under MicroC OS kernel, the tasks may be in one of the following state at a given point of time.
Dormant: The dormant state corresponds to the state where a task is created but no resources are al-
located to it. This means the task is still present in the program memory and is not moved to the RAM
for execution.
Ready: Corresponds to a state where the task is incepted into memory and is awaiting the CPU for its
tum for execution.
Running: Corresponds to a state where the task is being executed by CPU.
Waiting: Corresponds to a state where a running task is temporarily suspended from execution and does
not have immediate access to resources. The waiting state might be invoked by various conditions like
-the task enters a wait state for an event to occur (e.g. Waiting for user inputs such as keyboard input)
or waiting for getting access to a·shared resource.
Interrupted: A task enters the Interrupted (or ISR) state_ when an interrupt is occurred and the CPU
executes the ISR.
A task is usually created as non-ending function. The creation of a task is illustrated below.

r
t

I It creates a task with name MicroCTask. The task doesn't return anything. The argument to the task

d
n
I is passed through a pointer to void. Depending on the argument required the pointer can pass structure
· variables, other data types or function pointers to the task The task MicroCTask is in the 'Dormant' state
now.
You need to pass this task to the MicroC kernel to make it ready for execution. It is essential for as-
signing resources to the task MicroCTask. The MicroC kernel call OSTaskCreateQ or OSTaskCreateEx0
is used for this. These function calls take the address of the task, the priority assigned to it and the stack
size requirement for the task as parameters. OSTaskCreate() is the older version of the task allocation
1e call and OSTaskCreateEx0 is the enhanced version of it. Calling these functions allocate the memory
S·
for the task and put the task in the 'Ready' state. The usage of these funi.:~ions is illustrated below.
le
 ~ 'f'
" .:.~:

Introduction to Embedded Systems

,,,//:1'; ****~ * ***** * * ** * * *** *** **'** ** ** ******** *** **·** **** ******·**'Ir*******
)/~llocate re:3.ourc.eff ~or the task MicroCTa.sk
''t/Make the' ta'sk MfcroCTask 'Ready' foi: execution
/tD~clare stack as type OS_STK
::<DS STK 1'.askStk[1024];
,'.,iiTaskCr~a~teEx(Mic;oCTask,
!~'.2-'.~'.-'' ... ,,: _-.,_"···.,,_,"Ki ·--.,~,, -,<~t· , ,;-_-,--_.-./·
>··
(void,,*)
. .}·. _:-.-~\ .. ;"',s•--,, ~
o; & Tas~Stk,61Qz
•~":"<",":~~," -~
3 J; 1 0 il0,< &'I'~,s ~St)<JO l, 102 4,
\Jvoid*)
• :-<·:1'<. . '0, OS-:TASK, OPT STK CHK ) ;
~ i - .• ··-:· • -- •

The parameter MicroCTask specifies the entry point of the task MicroCTask. The second parameter
specifies the arguments for executing the task. The parameter TaskStk[J023) sets the top of stack and
'TaskStk[0J sets the bottom of the stack for the task. The other parameters are the task priority (10),
task ID (10), stack size (1024) and a pointer to user supplied memory location used as an extension of
TCB. Here it is not used. The last parameter specifies a task specific option like whether stack check-
ing is allowed or not, whether the stack needs to be cleared, etc. Here it is set for enabling stack check
option. It should be noted that the stack should be declared with type OS_STK. The value OS_STK_
GROWTH specifies whether stack grows downwards (OS STK_GROWTH=l) or upwards (OS_STK_
GROWTH=0). This value should be configured properly depending on the processor architecture and
the stack bottom, top and size should also be configured accordingly for creating a task.
uC/OS-II supports up to 64 tasks. Out of this 8 are reserved for the uC/OS-II kernel. Each task should
have a unique task priority assigned. No two tasks can have the same priority. In effect uC/OS-II sup-
ports 56 user level tasks. The priority.of tasks varies from O to 63, with O being the highest priority.
Considering the future expansions, uC/OS-II advices developers not to use the priority values 0, 1, 2,
3, OS_LOWEST_PRIO-3, OS_LOWEST_PRIO-2, OS_LOWEST_PRJO-1 and OS_LOWEST_PRIO.
-eurrently, the uC/OS-II reserves only two task priorities for kernel tasks. Under the uC/0S-II kernel,
the ID of the task is its priority. A Task Control Block (TCB) is assigned to a task when a task is created.
TCB is a data structure for holding the state of a task. It is essential for handling the state information
during a context switch. The TCB under uC/OS-II is r:epresented by OS_TCB. The following table gives
a snapshot of the important task creation and management routines supported by uC/OS-II.
.r~~£~2i:t,!l£:~ij ):;tit{~rJJl1!~~¥ifh··•..,...... ,
.OSTqskCreate0 Cr;ate a task and makes it\Ready'.for·~x~critlQ~:

OSTaskStkCheck0 Checks stack overflow for the. cre~tion of tasks. uC/OS-II does not automatically check for
~~~~~-~~ ' "

{J{>'.fift;~lJ!~.\,;,i};' ~' .
' ,:,~-\~''.::,:' ; _;_:~{-~;::;'._~y,:_~:,,
;~~i·
~ ::~~g~-~--

QSTimeDlyHMSMO Delay the .task. for the specifi~q ~llration. 4'he delay time i~ &pe¢ified ;by fh~ comqjniti9n
of hour,s (H); µii~Utt?S:(w: s~c.:Andi{~tand·p:iillisee<;md; (M),. Hoiii1vai9e ~a~ range[1ym
.0 to ·2ss,.minutes
• ;
value can:raiige"froni0
P; •/,"/ '/:.; )'\,_'.',•,i~:,~•.~•::•~, •,,: .. },{'',,,,;,,,,;,•'
, ..,t•• ~\y?'
w;\)'.,'.'.
fo 59, second's ·~aiue'~an rlingJ fromO t~:59 and
''. ✓; "° •,'' _ ', : ' > _..

' miHi,secqpd;V,B;/Ue can t311geJroin Q. tcr999. lleso1ution'depepgfon. clock rate. '

e -~:• : ',: ;.'· . ;•; '~ .-,,; • , ';,: • '

, ' : ''
VSUritfHl{R~i~~i&{r:,;~Jf {: .,. ' . ·:i~.:it. ,. .,~:,iJ~~lr't~~eith~~.~~, . , . . !¾?L: ,,c~,,1,.,,~'.:JJ/ft/ffff/:~~

t Please refer to the MicroC library reference manual for the parameter details of each function calL
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-II RTOS

iOSTaskDelO

er
1d
)),
of
k-
ck
r r~s$.tij~;i~J0.; ··";: t :?i(~J~niW~•~:&~;~Iafli;'fa!t?fr
1

r( Interrupt Service Routines (IS Rs) are not allowed to create a task. The stack statistics of a task can
nd be examined by calling the function OSTaskStkCheckQ. In order to get the stack statistics for a task, the
task should be created with the option OS_TASK_OPT_STK_CHK. The stack details of the stack for a
1ld task in terms of no. of bytes used and no. of bytes free in the stack are returned in a structure variable
lp- of type OS_STK_DATA. The execution time of this call is determined by the size of the stack and hence
ity. the call is non-deterministic. It is advised not to call this function from ISR due to its non-dyterministic
, 2, nature. The following code snippet illustrates the usage of this function.
[0.
1/****************************~*******t~***********************j*****
1el,
. / /Define variable of type OS ·sTK \DATA
:ed. OS - STK DATA staok mer\\i . - -
. . .
:ion · //Define 32 bit integer for holding ·stack size
ves INT32U stack size;
//Define vari~ble for holding return value
INT8U err;

//Get the stack details for task with priority 5

err OSTaskStkChk(5, &stack_mem);
if (OS NO ERR err)
stack size stack mem.OSFree + stack mem.OSUsed;
The function calls OSTaskSuspend0 and OSTaskResurneQ are used in combination to suspend and
resume a task. Whenever an OSTaskSuspendQ call is made by a task, the task is put in the 'Waiting'
state and the scheduler picks up the highest priority task from the 'Ready' list for execution. Suspend-
tion. ing of IDLE task is not allowed. The following code snippet iUustrates the usage of the task suspend
rom. function.
·'1.ria
//*******************************************************************
//Task implementation
void task(void *args)
{
while (1)
 Introduction to Embedded Systems

A task can delay itself by calling either OSTimeDly0 or OSTimeDlyHMSM0 function. Upon calling
these functions, the task is put into the 'Waiting' state. The task becomes ready for execution when the
delay time expires or when another task resumes the delayed task by calling a task resume function.
Task delaying is the mechanism by which a task can voluntarily relinquish the CPU to other tasks when
it is waiting for any events to occur. A task can only delay itself and cannot impose delaying of other
tasks. The activation of the delayed task to 'Ready' state from 'Waiting' state, when the wait period ex-
pires is done by the function OSTimeTickQ. The function OSTimeTick0 is the Interrupt Service Routine
(ISR) for the system timer clock and the kernel executes it. Users don't need to bother about it. A task
which is currently in the waiting state introduced by the self delaying can be resumed by another task.
The function call OSTimeDlyResume0 resumes a specified task which is currently in the 'waiting' state
induced by self delaying. A task which is self delayed by invoking OSTimeDlyHMSM0 function cannot
be resumed by another tasks if the combined delay set by the hour, minute, seconds and milliseconds
parameter exceeds 65535 timer ticks.
The task self delaying and resuming it from another tasks technique is a good approach for building
applications where one task requires waiting for I/O operations. The task involving Input operation (e.g.
Waiting for a key press) can self delay it and key press event can be handled in an Interrupt Service
Routine (ISR) and the ISR can resume the delayed t~sk upon receiving the key press event. The follow-
ing code snippet illustrates the usage of task delay and task resuming functions.
//****************************'**************************************
'·
//Task implementation
void taskA(void *args)
{ .

while (1)
{
I /Ex_ecute the task specific details
I/ ..........................:..................... ........................... ..
I/ ................·........................................................... ..
//Delay· the task for 5 Timer ticks.
OSTimeDly(S);
/ /Res_t of the task
I/ .................................................................................
}
}
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-ll RTOS

The function pair OSTaskSuspendO and OSTaskResumeO can be used for suspending a task uncon-
ditionally and resuming the suspended task. If a task which is being suspended is delayed by task delay
call, the task is resumed only after the task is resumed from suspension and both the time expires.
Tasks can be deleted by calling OSTaskDelO. The task which is being deleted is kept in the 'Dormant'
state and it can be recreated, if needed by calling task creation functions like OSTaskCreateO or OSTa-
skCreateExO. Proper care should be applied in the usage of OSTaskDelO function. Imagine a situation
where Task 1 is holding a shared resource, a semaphore and Task 2 attempts to delete Task 1 by execut-
ing OSTaskDelO. Task 1 wili be moved to the 'Dormant' state and this will lead to the locking of the
semaphore used by Task 1 and this semaphore will not be available to other tasks - leading to starvation
of tasks. The function OSTaskDelRe.q,{) makes task deletion safe by ensuring that the task is not deleted
when it is holding a shared resource.

11.2.2 Kernel Functions and Initialisation

The kernel needs to be initialised and started before executing the user tasks. MicroC/0S-II provides
OS kernel initialisation and start routines. The MicroC/0S-II kernel initialisation and OS kernel start is
written as part of the startup· code which is executed before the execution of user tasks. The OS kernel
initialisation function OSiniiO is executed first. It performs the following operations.
1. Initialise the different OS kernel data structure
2. Creates the idle task OSidleO
The idle task is the lowest priority task under the MicroC/0S-II kernel and it is executed to keep the
CPU always busy when there are no user tasks to execute. User tasks are not allowed to delete or sus-
pend the 'Idle' task. The following code snippet illustrates the implementation of 'Idle' task.
//*******************************************************************
//Idle Task implementation
0S.:.._T·askidle (void *args)

~ijJli):e {.l )

OS ENTER_CRITICAL(;) ;
·osrctleCtr++;
 Introduction to Embedded Systems

OS
istt
CP
exe

It simply increments a counter to keep the CPU always active. Depending on the power saving re- be
quirements, the IDLE task can be re-written to include the CPU specific power down modes. OS
The MicroC/OS-II kernel runs a statistical task for computing the percentage of CPU usage. The fur
statistical task is created with priority OS_LOWEST_P/UO 1 ar).d it is executed in every second. The OS
function call OSStatinit() sets up the statistical task related actiyities. This function must be called be- be
fore OSStartQ. The OSStart() function starts the multitasking. It is invoked only after invoking OSlnitQ. sy~
It starts the execution of the highest priority task from t~e 'Ready' list. It never returns to the calling
function. There should be at least one task to execute. The following code snippet illustrates the OS nef
initialisation and start operations. of
wh
tee
lov

11.2.~ Task Scheduling 9

J
The MicroC/OS-II support preemptive priority based scheduling. Each task should be assigned a unique
I
priority ranging from 0 to 63 with 0 being the highest priority level. The four highest priorities (0 to I
3) and the four lowest priorities (63 to OS LOWEST PRJO - 3) are reserved for the kernel. When the 0
kernel starts, it executes the first available highest priority task. A task rescheduling happens if any one I
of the following situation occurs. I
1. Whenever high priority task becomes 'Ready' to run or when a task enters the 'Waiting' state due to I
the invocation of system.calls like OSTaskSuspend(),OSTaskResume(),OSTaskDel(),OSTimeDly(), }
OSTimeDlyHMSM(), OSTimeDlyResume(), etc. }

2. Whenever an Interrupt occurs, the tasks are rescheduled upon return from the Interrupt Service
Routine (ISR).
I
Pr
In general, the task scheduling happens at the task level and ISR level. The task level scheduling is as
executed by the kernel service OS_Sched() when a system call occurs. The ISR level task scheduling is
done by the function call OSlntExit(). When an OSintExit() call is executed, the kernel is notified that l]
the ISR is complete and the kernel checks whether there is any high priority task is 'Ready' for sched-
uling. If a high priority task is ready for scheduling, the ISR returns to the high priority task instead of Tl:
returning to the interrupted task. m1
For task level scheduling, the software interrupt OS_TASK_SW() is triggered and the context switch
handler OSCtxSw() is executed as ISR for this interrupt. The service OSCtxSw() is _part of the MicroC/
l
I
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-1/ RTOS

OS-II kernel service and is responsible for handling the context switch operation. It saves the CPU reg-
isters and Program Status Word (PSW) to the stack of the preempted task (context saving) and loads the
CPU registers and PSW from the stack of the highest priority task (context retrieval) which is going to
execute.
The task rescheduling will not take place if the scheduler is in the locked state. The scheduler can
be locked by invoking the system call OSSchedLock0. Proper care should be applied in the usage of
OSSchedLockQ. Once the scheduler is locked with this call, the application should not call any other
function calls, which suspends the execution of the current task, like OSTaskSuspend0 ,OSTaskResume 0,
OSTaskDel0, OSTimeDlyQ, OSTimeDlyHMSMQ. Since the scheduler is in the locked state it will not
be able to schedule another task for execution and the current task is already in the suspended stage, the
system hangs-up.
The scheduling can be resumed by calling OSSchedUnlockQ. The MicroC/OS-II kernel supports
nested locking of scheduling up to 255 levels deep. Scheduling is enabled only when the same number
of scheduler unlocking calls as that of scheduler locking calls is executed. Interrupts are serviced even
when the scheduler is in the locked state. The scheduler locking and unlocking mechanism is used as a
technique for exclusive access to shared resources (An implementation of mutual exclusion). The fol-
lowing piece of code illustrates the usage of scheduler locking and unlocking functions.

I I ......... .... " . .. . , .:··· ,, . ·· ·· , · · .... ,: }"' <: ": :

//Unlock the scheduler,
OSSchedUnlock (); · :.
/ /Rest of the tas.k
// ...................................... ·........................................
I 1................................................................... '...... ·.·...
}
}

The priorities associated with a task can be changed dynamically. The function call OSTaskChange-
PrioQ changes the priority associated with a task. The function takes current priority and new priority
as arguments,.

11.2.4 Inter-:Task Communication

The MicroC/OS-II kernel supports the following inter-process communication techniques for data shar-
ing and co-operation among tasks
1. Mailbox
2. Message queue
 Introduction to Embedded Systems

Mailbox and message queues are same in functionality. The only difference is in the number of mes-
sages supported by them. Both of them are used for passing data in the form of message( s) from a task w
to another task(s) or from an ISR to task(s). de
Mailbox is used for exchanging a single message between two tasks or between an Interrupt Service If
Routine (ISR) and a task. Mailbox associates a pointer pointing to the mailbox and a wait list to hold pc
the tasks waiting for a message to appear in the mailbox. The following table gives a snapshot of the SC
important mailbox related routines supported by MicroC/0S-Il. w:
eti
as
/Y(
pr.
be
fu ::
us.
0,
i ..
Same as OSMboxPost0. function call: AllowsJhe broadcasting of message to all tasks waft:i~'i, m.
for the message. The b.r9adcast option c~n,be setintlle options parameter. · . {'~i~";' Tl
m.
fo
us
th
de
ill

OSMboxAccept0 Used for retrieving message froni a rnililbox. S4nilar to OSMboxPend0 in functioning btl,t.
differ in the way it operates. It allows a task to check whether a message :is available in'tlie
mailbox. Unlike OSMboxPend0, the calling task is not blocked ('Pended') if the.re is rib
message to read in the mailbox.
'·•:iflfdgtiation,lil\'ouvt?,~Cajkilbox}W.lie,%•.
;in(.,,nii~,1;;ff~fa1t\dltfll1~• . ,c_ .•

OSMboxDe!0 Deletes a mailbox. Option for specifying whether the mailbox needs to be deleted immediately
or only when the pending operations on this mailbox are completed.
A mailbox is created with the function call OSMboxCreate(void *msg), where the parameter msg is
a pointer holding the initial message. If this is a non-null value, the mailbox holds the message pointed
by msg. If msg is a null pointer, the mailbox is created without any messages present initially. This func-
tion allocates an Event Control Block (ECB) to the mailbox and returns a pointer of type OS EVENT I
(
to the allocated ECB. The Event Control Block (ECB) is a data structure holding information like,
(
the event associated, list of tasks waiting for this event to occur, etc. A task can post a message to the
(
mailbox if the task knows the ECB pointer for the mailbox. Along with the ECB pointer of the mail-
box, the task passes, a pointer to the message which is to be posted to the mailbox, as argument to the
OSMboxPost(OS_EVENT *pevent, void *msg) function. If the mailbox is not empty when a task is (

II
\
t Please refer to the Micro( library reference manual for the parameter details of each function call.
 An Introduction to Embedded System Design with VxWorks and MicroCIOS-Il RTOS

trying to post a message, the task returns immediately. On the arrival of a message in the mailbox, it is
delivered to the highest priority task waiting for the event and the message is deleted from the mailbox.
If the priority of the highest priority task waiting for the message is higher than that of the message
posting task, the message posting task is preempted and the highest priority task is executed by the
scheduler. A task can broadcast a message to all tasks waiting for a message by posting the message
with the function call OSMboxPostOpt(OS_EVENT *pevent, void *msg, INT8Uopt). The 'opt' param-
eter should be set as OS- POST- OPT- BROADCAST for broadcasting a message. If this .
parameter.
is set
as OS_POST OPT_NONE, this function becomes equivalent to OSMboxPost. The functions QSMbox-
Peiid0, and OSMboxAccept0 can be used for retrieving a message from the mailbox. OSMboxPend0
provides option to set the function call as either a blocking call till a message is available in the mail-
box or till a wait period specified in the parameter list. OSMboxAccept0 is a non-blocking call. This
function will not block a calling task when there is no message available in the mailbox. T~is can be
used by IS Rs to check the availability of messages in a mailbox. A task can delete a mailbox by calling
OSMboxDel(OS_EVENT *pevent, INTBU opt, INT8U *err). The parameter 'opt' specifies whether a
mailbox needs to be deleted immediately or only when the pending operations on this mailbox are over.
The value OS_DEL_NO PEND for 'opt' sets the first choice and a value OS_DEL_ALWAYS deletes the
mailbox immediately. Proper care should be applied in the usage of this function. There are possibilities
for tasks to access a deleted mailbox. This may result in _unpredicted behaviour. Also tasks which are
using the function OSMboxAccept0 for checking the availability of a message may never know about
the non-availability of a mailbox. Hence use this function judiciously and as a precautionary measure
delete all tasks which uses the specified mailbox before it is being deleted. The following piece of code
illustrates the usage of mailbox functions:
• ,, - , ' ' **
I lt* * ** ** *,* * ***** * ** ****~~-*** **~ * * *lr,**.*-** *i* * ** * **·*******~*-,*. *** ** **
' • ,,,, A ,- ' ,

:.~.incl0dE: ~includE:s :h>

· //DE:firie /['ask lPs.
#d_efine :rASK
.#define iASK i ID
#define TASK 2ID

//Define Task Priorities for Firsl Task, Task 1 and Task 2

#define TASK- FIRST- PRIO 5

l #define TASK 1 PRIO 6 ,

#defin~ TASK 2 PRIO 7

//Set the default stack size fQr all tasks

#define TASK STK SIZE 1024

/ /Defin1e stack size for tasks

• OS_STK TaskFirstStk[TASK_STK_SIZE]; // First task's stack
OS_STK TasklStk[TASK_STK_SIZE]; I I Task li' s task stack
OS STK Task2Stk[TASK_STK_SIZE]; , / I Task 2' s task stack
\

//Define ECB pointer for the mailbox

OS EVENT *Mbox;

void main {void)

 Introduction to Embedded Systems

MicroC OS

, ll * * *'***'t*
/ /.ImpJeme.ntation of ..TaskFirst ·
void :ir;skft~sf-_(voiq '* args) ·
{
//Initialise statistics task
. OS§.tatlnit () ;
j /Create Mail.box
Mbox = OSMboxC~eate ( (void ..{) O)J
//Create Taskl
OSTaskCreateExt(Taskl,
(void *) 0,
&TasklStk[TASK_STK SIZE l],
TASK_l_PRIO,
TASK_l_ID,
&TasklStk[0],
TASK~STK_SIZE,
(void *) 0,
OS TASK OPT STK CHK);

//Create Task2
OSTaskCreateExt(Task2,
(void *)0,
&Task2Stk[TASK_STK SIZE - l],
TASK_2_PRIO,
TASK_ 2_ ID,
&Task2Stk[0],
TASK STK SIZE,
(void *) 0,
OS TASK OPT STK_CHK);
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-IJ RTOS

while (1)
{
//Do Nothing. Simply sleep for one timer tick
OSTimeDly(OS_TICKS PER_SEC);
}
}

/ /* * * * * ** ***·*~* *** ****·* ***** * * * *** * * *** * * * ** ** * * *** *** * ** *** *****'I<*
//Implementation'"':qf Taskl
voi.d '.I'askl (void :*;,'~s)
{ \
\ .
./ /Define pointe:i;- tp. me~sage
char ms~; \ ·

msg = · .'0';
while (1)
{
/ /Execute the task specific details
// ... :···• ...... ·....... ·........... ·............ ·............. ·· .. .......... .
_

!/ .... ";· .. .,..........' ........,·..... -- ...... ·............ - ............... '

1/PosV a ITle!fia:ge to 4::he mailbox Mbox.
OSMb'okP~()sl(Mb,¢i; (void *) &msg);
I /Rest·_of the. task
I/ ................................. ·.... .-..................................... ..
// ......................... ·................................... -................ ..
}
}
//*******~****;*********************;********************************
//Implementation of Task2
void Task2(void *args)
{
//Define pointer to message \
char* msg;
//Define Returri value handling variable
INT8U err;

while ( 1)

I /Execute the task specific details

I/ ................................................................................ .

::~=i~%iX :~i::i:~!;i: !~=~~:!~:~x Mbox.

msg = (char *)OSMboxPend(Mbox, 0, &err);
//Rest of the task
I/ ............................................................................... ..
I/ ................................................................. ,............. ..
}
}
 Introduction to Embedded Systems

The sample application creates a main task TaskFirst which creates a mailbox and two tasks namely
Task] and Task2. Task I posts the message '0' to the mailbox and Task2 reads the mailbox to retrieve the
message present in it. The startup tasks, viz. the initialisation of Micro( kernel (OS/nit()), main task
creation and starting of multitasking (OSStart{J) 1s done by the main function.
Message queue is same as that of mailbox in operation; the only difference is-mailbox iE designed
for handling only a single message whereas message queue is designed for the handling of multiple mes-
sages. Message queue is used for exchanging a message data between two or more tasks or between an
Interrupt Service Routine (ISR) and tasks. Message queue associates a pointer pointing to the Message
queue and a wait list to hold the tasks waiti11:g for a message to appear in the Message queue. The following
table gives a snapshot of the important message queue related routines supporied by MicroC/OS-II.

~iJfit!fijil~tliU! ,: )>~~ffipflon
. OSQc;.re.a{f0 Creates anq ... . l1}¢s'.$age queue. Anarray"of pointers isallocated fotsto
' :'.> """ The stze of the ~essage stor<ige area (size of the pointer array} is specified as the:'
function. · ·

message queue. ·
Jt-,:t~anie)iro$QP6st0,' ·• ., ·. ~lf4wfthe t;rbiidgastmg ·ofrii.essdgt''
\\Y-~t~sjgeJor~~;r~Jt,,,. g:'tfat(or111~:p{blstg~ quJiiltnJ•bro ·
1

.. '.' ;:qllelle;ogti~n is set oyJh ran1'e;et,. . .. .

Used for retrieving messagesfrom a mes~age queue. If a message is available in the ,
at the time of calling thisTuµction, it is retrieved through the pointer and the tnes§~g,
from the message queue. If message is not available in the message queue at the time'qf C\l
function, the calling task is blocked and it is put in the message wait list queue assoQfat~fl
message queue. A task can wait until a message is available in the message queue or tiH atµgeo.~t
occurs. The timeout value for waiting can be specified in the 'timeout' argument of this fuhctipp
call. The 'timeout' value is specified in terms of clock ticks. It can take values ranging'froiri0.to
65535. A value or"0 indicates wait until a message is available. · ··· '·
QSQAcceptO Used for retrieving messages from a message queue. Similar to OSQPend0 in fun ·
differ in the way it operates. It allows a task to check whether a message is availaole iµ
queue. Unlike OSQPendQ, the calling task is not blocked ('Pended') it there is no m'
0

in the message queue. · · ·

OSQQi1e1yQ Retrieves infom1ation about the message queue. The information is retrieved in a data structure of
type OS_Q_DATA. It is used for getting infonnation like, what is the message queue size, whether
a message is available in the message queue, is there any tasks waiting for the messages and.if.yes
how many tasks, etc.
Flushes the message queue and deletes all the messages present in it. The time r~qu,freQJ~
this function is fixed regardl~ss of the number of messages present, and the number ort'a{k:{
(in case no messages are present in the message queue). · · · ·············
OSQDel() Deletes a message queue. Option for specifying whether the message queue needs to be deleted.
immediately or only when the pending operations on this message queue are completed.
 An Introduction to Embedded System Design with VxWorks and MicroCIOS-1/ RTOS

A message queue is created with the function call OSQCreate(void **start, INTBU size), where start
is the base address of the message storing area and size is the size of the message storage area in bytes.
This function allocates an Event Control Block (ECB) to the message queue and returns a pointer of
type OS_EVENT to the allocated ECB. A task can post a message to the message queue if the task knows
the ECB pointer for the message queue. Along with the ECB pointer of the mailbox, the task passes a
pointer to the message which is to be posted to the message queue, as argument to the OSQPost(OS .
EVENT *pevent, yoid *msg) function. If there is no room for a message in the message queue when;
task is trying to post a message, the task returns immediately. On the arrival of a message in the message
queue, it is delivered to the highest priority task waiting for the event and the message is deleted from
the message queue. If the priority of the highest priority task waiting for the message is higher than
that of the message posting task, the message posting task is preempted and the highest priority task is
executed by the scheduler. A task can broadcast a message to all tasks waiting for a message by posting
the message with the function call OSQPostOpt(OS_EVENT *pevent, void *msg, INTBU opt). The 'opt'
parameter should be set as OS_POST_OPT_BROADCAST for broadcasting a message. If this parameter
is set as OS_POST_OPT_NONE, this function becomes equivalent to OSQPost. This function can also
serve the purpose of the function OSQPostFrontO, which posts the message to the front of the message
queue. For this, set the 'opt' parameter as OS_POST_OPT_FRONT. The functions OSQPendO, and
OQSAcceptO can be used for retrieving a message from the message queue. OSQPendO provides op-
m1
tion to set the function call as either a blocking call a message is available in the message queue or
till a wait period SP;ecified in the parameter list. OSQAcc,eptO is a non-blocking call. This function will
not block a calling1ask when there is no message available in the message queue. This can be used by
ISRs to check the availability of messages in a message.queue. A task can delete a message queque by
calling OSQDel(OS_EVENT *pevent, INTBU opt, INTBU *err). The parameter 'opt' specifies whether
a message queue needs to be deleted immediately or only when the pending operations on this message
queue are over. The value OS_DEL_NO_PEND for 'opt' sets the first choice and a value OS DEL_4.L-
WAYS deletes tJ}e message queue immediately. Proper care should be applied in the usage of this func-
tion. There are possibilities for tasks to access a deleted message queue. This may result in unpredicted
behaviour. Also tasks which are using the function OSQAcceptO for checking the availability of a mes-
sage may never know about the non-availability of a message queue. Hence use this function judiciously
and as a precautionary measure delete all task which uses the specified message queue before-it is being
deleted.
Message queue and mailbox operates on the same principle. However message queue supports mul-
tiple messages and also provides option to post a message as urgent message, by posting it in front of the
message queue. Mailbox holds only one message at a time and there is no pro.vision to post a message

I
to the mailbox until the existing message is read by a task. Message queue supports emptying of the
message queue by flushing it.

) 11.2.5 Mutual Exclusion and Task Synchronisation

In multitasking environment multiple tasks execute concurrently and share the system resources and
data. The access to shared resources should be made mutually exclusive to prevent data corruption and
'race' conditions. Synchronisation techniques are used by tasks to synchronise their execution. For ex-
ample, one task may be waiting for a resource while it is being held by another task. The task which is
currently holding the resource can inform the waiting tasks when it releases the resource. MicroC/OS-II
provides exclusive access to shared resources through the following techniques.
1. Disabling task scheduling
 Introduction to Embedded Systems

2. Disabling interrupts
3. Semaphores for mutual exclusion
4. Events (Flags) for synchronisation
1
In a multitasking environment, problems arise only when a task is preempted by another task, when
the task was accessing a shared resource and the task which preempted it also tries to access the re-
source. This may lead to inconsistent results. The easiest option to solve this problem is prevent task
preemption by disabling the task scheduling when a task is accessing a shared resource. The task sched-
uling is re-enabled only when the task completes the accessing of the shared ~esource. Interrupts are still
identified and serviced even if the scheduler is in the locked state. This technique is suited for control-
ling the access to resources shared between tasks and it will not serve the purpose of exclusive access of
resources shared between a task and Interrupt Service Routine (ISR). The funl3tion calls OSSchedLock0
and OSSchedUnlock0 are used for locking and unlocking the scheduler respectively.
We have seen that the disabling of task scheduling will not serve the purpose of exclusive access
to resources shared between a task and ISR. The interrupts should be disabled to ensure error-free op-
eration when a task is executing in the critical section of code (The piece of code which corresponds
to the shared resource access). The interrupts are re-enabled when the task complete the execution of
the critical section code. Disabling and enabling of interrupts can be done by the MicroC/OS-II sup-
plied macros; OS_ENTER_CRJTICALO and OS_EXIT_CRJTICALO respectively. The implementation
of these macros is processor specific. These macros need to be ported as per the target processor specific
implementation of Interrupt enabling and disabling. These macros are defined in the MicroC/OS-II
header file 'os_cpu.h'. The usage of these 'macros' are illustrated below.
l/**t**f**.*****'-k***.
71/fnipl'etnetrt'at:idn
void ..... (vo.id'*atgs)

while· (1) ·

//Execute the task specific details

11 ................................................................................ .
11 ................................................................................ .
//Disable Interrupts
OS ENTER_CRITICAL();
//Enter Critical section.
//Access shared resource
Counter++;
//Leave Critical section.
//Enable Interrupts
OS_EXIT_CRITICAL();
//Rest of the task
I( ................................................................................ .
I/ .................. ·............................................................ .

Here the variable 'Counter' is shared between a task and ISR. The accessing of it is made exclusive in
the task by disabling the interrupt just before accessing the variable and re-enabling the interrupts when
the operation on the variable is over.
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-II RTOS

Disabling of interrnpts may produce adverse effects like impact on the real time response of the sys-
tem. It is advised not to disable interrupts for critical section access operations which are lengthy.
Semaphore based mutual execution is the most efficient and easy technique for implementing ex-
clusive resource access. Semaphores control the access to shared resources as well as synchronise the
execution of tasks. The MicroC/OS-Il supports two different types of semaphores namely counting
semaphore and mutual exclusion semaphore (mutex).
The counting semaphore is used for restricting the access to shared resources and as a signalling
mechanism for task synchronisation. It assoc_iates a count for keeping track of the number of tasks using
the semaphore at a given point of tune. It ~lso holds a wait list queue for holding the tasks which are
waiting for the semaphore. The following table gives a snapshot of the important counting semaphore
related routines supported by MicroqOS-IL .

:}11~~~,~~~!I,:.,1'.f]§, D~s.c~ipti~n
OSS/inCYeateO . a
Creates and initialises counting semaphore. 'It takes a count va
value can range from O to 65533. Each time _the semaphore ac is
decremented by 1. When the count reaches 0, the semaphore is not
acquire the sema · · ·
~··',, :c\ -·,-\:; 3
_,;. ~,.,:-0 .:::..:··,. ,.,.,

:dfthe semaphore,
Used by a taskfOF a~q~iring a seµ1ap4ore.ifthes~ttiaphore is av;ilatrl~'i;ruf
with the semaphore is greateTili&~ 0) .~t the, tJrotof calling 'this ,fuilcticn1V~(
the task an<f the countasso9i~tedwith the:'8~claphore is decremented ~yo9e
is not available (The count asso9iated.with t~~ semaphore is zeroTat ili,~
function, the callingtask is blocked and itis putin the semaphore waiflfst:q
with the semaphore. A task c'an waituntil the s6rriaphore is av~iiable p1{}iil£ OUL()
The timeout value for waiting can be specified in the 'timeout' argument of thi~ functiori:"oalL
The 'timeout' value is·specified in terms of clock ticks. It can take values ranging from:O]q
65535. A value of 0 indicates wait until the semaphore is available.
OSSemAcceptQ ·.•. Used for acquiring a semaphore. Si~ilar to OSSemPendO infunctioni · ·
·<
operates. It allows a taskto Check ~hether a sciinipb.o~e is avai~it51~: U
calling task is not blocked ('Pended') if the semaphore is not available.
OSSemQueryQ Retrieves the infonnation about the semaphore. The i~formation is retrieved in a data stru9ture
of type OS_SEM_DATA. lt is used for getting infonnation like, the semaphore count, wh¢ther
a semaphore is available, is there any tasks waiting for the semaphore and if yes how many
tasks etc.
OSSemSetO It is used for changing.the current count value associated with the.. seffi · ·
associated with the semaphore
isreset.io the::walue specified in th~J
function. If the semaphore colifif is Oat the !fine of ex½cutirig·this .
only if there are no tasksw;i.iting this s6n1~phqre. This .f4hctiqnfor
signalling mechanism for task synchronisation and not for protecting sh

t Please refer to the Micro( I1hran I c 1c1 CllLc· 111anual for the parameter dcm!ls of each function call
 Introduction to Embedded Systems

{OSSemDelO
,,_.,,
Deletes a semaphore. Option for specifying whether the semaphore needs to be .deleted
·{~:
th,--. immediately or only when the pending operations on this semaphore .are over. Proper care
sliould be applied in the usage of this function. There are possibilities for tasks to access a
deleted semaphore. This may result in unpredicted behaviour.
The mutual exclusion semaphore or mutex is a binary semaphore. It differs from the ordinary sema-
phore in the sense it implements provisions for handling priority inversion problems in task scheduling.
The mutual exclusion semaphore (mutex) temporarily raises the priority of a low priority task holding the
mutex to a priority above the highest priority of the task which tries to acquire the mutex when it is be-
ing in use by a low priority task. The mutex object associates a flag to indicate whether the mutex object 1
is available or currently in use and a priority to assign to the task owning the mutex, when another high
priority task tries to acquire it. It also holds a waitlist queue for holding the tasks waiting for the mutex.
Normally the mutex object elevates the priority of a task holding it to a priority value same as that
of the priority of the highest priority task trying to acquire it. However MicroC/OS-Il doesn't support
the existence of two tasks of the same priority. Hence a small work around is implemented to overcome
this issue. Under MicroC/OS-II, the priority of the task holding the mutex is elevated to a value which
is greater than the highest priority of the task which is trying to acquire it, when it is being held by a
low priority task. The priority reserved to the mutex is known as Priority Inheritance Priority (PIP).
PIP should be an unused priority by tasks. The following table gives a snapshot of the important mutual
exclusion semaphore (mutex) related routines supported by MicroC/OS-II.

u i&cieateO::: :-:', .,treates an.ti initialises:amut~x. ' ,... ...

:<{~_;\_' · :•," -'"=·~' ·~. -~ ~:-:, ~ ·i-:The~mutei is cf~~ed'with Jtaie,'
· •. ::' :[~cre¥on of the n{~texi (poiqtei'tti'a~:E

CJO.
i:tJ\ig!~g!frofttL fo ~$(
OSMutexAcceptO Used for acquiring a mutex, Similar to OSMutexPendO in furictioriing but cliffer ifi.tge ~ray
it operates. lt allows a task to check whether a mutex is available. The functipn f~tµfnf,l)f
the mutex is available, else returns 0, Unlike OSMutexPendO, the' calling task is notoloclced
('Pended') if the rrp.itex is not available.. . .
O§MutexPof/0 •,.Sigl)als. th~ ,·· ·11abtJHy,ofa:mutef"A.tas~ can ,u&ethiscall to inf'orm'th~ w~ •;•c "'.
. ' .. mutex:is a:; . ·.' . ,;:rffeJoll6~1fid,'actio~st~keip1;6e dµ;#ie exl~µti.bh of.th1,
1. The flag~sdodated with themuie~ is ;,ef~s 1, '(~µtiii [i. v~hie 'is
set asf
2. Iftl;l~pii6nty ofthe task holdingthe . miitex was,raised t9thei>1P., itis brqu
,origY:~!J?Jtority; gJtJ1r . ,
3. <I,f~1~e · n~l- ·· · %l~!l1\lti~1f•i
· an~;. . :8s~cJ •. .. ·~ }◊ {M1!te.l
;_mutf~lS'.ffi?t~.Y{(tfii~J?(, .· '?:' _·s~:_:~;r:;:_: -~ ·':\{:__ ., .
4. Ifthe priority o~th~task ·.· ?cqutte~ t e mutex'is greater.than that
released the mutex, the t~kwhich.releasedtlie mtitex ispe:tided;
5. A rescheduling of tasks is perfo~~d. . . .

I
t Please refer to the MicroC library reference manual for the parameter details of each function call.
 An introduction to Embedded System Design with VxWorks and MicroCIOS-ll RTOS

OS/lf,utexQueryQ

The following code snippet illustrates the usage of mutex.

I !***t,i:;t.i*tt:*.**t***** **t,t:*t.****:ti* *t;*l-X'*-*f**
#includ.e:::<inch1d€S .h> ,: , , ' - , • ::/ :>r:.,: '; {~:~:, •
/ /Diftne T?;~k IDs fo,l
.Fi~'1tc T.ask:. ;'i'a:sf,:l,,, (i;ch'Tfl:fk:,. 2
#defin~,'IDAsK:< :FIRST in 1 ,- ✓ ~. "••·, ~~::.--,,:"

- - ,

#defin\';. ".!'ASK 1 ID 2
#define. TASK :2 ID 3

//Define Task P~iorities for First TasJs:, Task 1 a,nci Task. 2

#define· TA$.K-F'1RST 'PRI0 10
#define TASK l,PRIO 11
#defipe 'rl\:SK-:- 2-PRIO 12

. I /Set ehe €ie:fault stack size for all tas)<s

.. #'define TASK STK SIZE 1024

I /Define stack size for tasks .

OS STK TaskFirstStk[TASK_STK_SIZE]; // First task's stack
OS STK TasklStk[TASK_STK_STZE]; // Task l's task stack
OS_STK Task2Stk[TASK__ STK_SIZE]; // Task 2's task stack

//Define ECB pointer for the mutex

OS_EVENT *MyMutex;

void main (void)

{
//Initialize MicroC OS
OSinit () ;

//Create the first task.

OSTaskCreateExt(TaskFirst,
(void *) 0,
&TaskFirstStk[TASK_STK SIZE - 1],
TASK_FIRST_PRIO,
TASK_FIRST_ID,
&TaskStartStk[O],
TASK_STK_SIZE,
(void *) 0,
OS TASK OPT STK_CHK);
 Introduction to Embedded Systems

I
// Start multitasking
OSStart();

//**************************~****************************************
//Irni::lementation of TaskFirst
void Task,Fiis~ (void *args)
{ .
l
//Variable for holding function return values
INTSO err:,;;. c: · .
/1/Iriiti.hi.ze :statistics task
OSSti3.UniJ(); ·
'//Creat:eiMutex with PIP 9
MyMutex = OSMutexCreate{9,&err);
/lC::r'eate Taskl
OSTaskCreiteExt(Taskl,
(void *)O,
&TasklStk[TASK STK SIZE - 1],
TASK_l_PRIO,
TASK_l_ID,
&TasklStk[O], ·
TASK_STK_SIZE, I

i
I

{void *) 0, \
OS TASK OPT_STK_CHK);

//Create Task2
OSTaskCreateExt(Task2,
(void *) 0,
&Task2Stk[TASK_STK SIZE - l],
TASK_2_PRIO,
TASK_2_ID,
&Task2Stk[O],
TASK_STK_SIZE,
{void *) 0,
OS TASK OPT STK_CHK);
while {1)
{
//Do Nothing. Simply sleep for one timer tick
OSTimeOly(OS_TICKS_PER SEC);

//*******************************************************************
//Implementation of Taskl
void Taskl(void *args)
{
//Variable for holding function return values
INT8D ere;
while (1}
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-11 RTOS

//Execute the task specific details

I/ .............................................................:...,...............
I/-.. _. ............................................................... · .......... .
//Acquire Mutex. ·
OSMut,exPend(MyJ;11.1tex,
. //Code
I

· 1lfi./*.* * **.* *}*i't* *.* **~ ** * **\"¾**"k0f

//Implementa_tion. of Task2
t~;i-d Task2f;o}d. "args) ..
//Va,riable. t'q~ :Bb\dii}g.
riiJT·su ~rfJ'
while (1)
·-c-'.
//E~ecute the task spetific details
I/ ................................................ ,.. ,..:......... ,............_.....
// ....:.....................:.................................::..:.. :::..:.. :.. :.. ,•,·

/ /Acquire Mute?--~
OSMutexPehd (MyMutex, 0, &eir);
I /Code for acc:es~ing~ Shared ·Resource
I/................................................................................. ..
//Release Mutex
OSMutexPost(MyMutex);
//Rest of the task
I/ ................................................................................ .
I/ ................................................................................ .
}
. }

The sample application creates a main task Task.First with priority I0. which creates a mutex MyMu-
tex with PIP 9 and two tasks namely Task] (with priority l l) and Task2 (with priority 12). Task] and
Task] contain critical section access. The mutex Ml'Mutex is used for acquiring exclusive access to'~he
critical section. Each task releases the mutex after they exit the critical section of code. .
It is possible to associate a name to the Event Control Block (ECB) which is associat~d with a sem~-, 1

phore. mailbox, message queue or a mutex object. The function call OSEventNameSet' (QS ~EVENT *pe-\
1·enr. char *pname, INT?lU *err) associates the name holding by the character string P8inted by pnam<J 1

to the entity pointed by the ECB pointer pevent. Similarly the function OSEventNameSGet (OS EVENT
*pcvent. char *pname, !NT8U *ffr) retrieves the name associated with the object pointed by the Ea:t·
po111ter pe1·e11t into a character string pointed by pname. These functions are mainly used for associatirtg
a name with a resource for debugging purpose.
 Introduction to Embedded Systems

Event flags are another mechanism suppo1ted by MicroC/OS-II for task synchronisation. You can
create a group of event flags and can assign specific meaning to each bit present in the event flags group. i
Tasks or Tasks and ISRs can modify or access these event flag bits to synchronise their execution. The
following table gives a snapshot of the important event flag related routines supported by MicroC/OS-II
for task synchronisation.

Creates and initialises an event flag group. It tal<es the initial value that
for flags as one parap;ieter. Succes,~ful creation of the event flag· group r~. .
fo the,Eyent Fl~gGroup (QS_FL1:G::.GRP) associated with the event~i

of
u;ed by a taskt6 ;\'{ail for.the arrival a specific combination offI
flag group. Ttie':flags' parameter of the furiction call specifies whicb:' .
to be checked and the parameter 'opt' specifies the type ·of event bit dhfp
. be any one 9f the following type. ·· •
l. OS_FLAG_WAIT_CLR._ALL: Check allspecified bits in the flags
2. OS- FLAG- WAIT- CLR- ANY: Check any specified bit in tl:ie flags. Ts.
','' ,;;:,

3. OS_FLAG_WAI(_SET_ALL: Check all specified bits in th<:; flagsjs

4. OS_FLA G:._WAIT_SET_ANY: Check any specified bit in the flagsf(',.,,.,.,
The flag OS_FLAG_CONSUME can be combined with the abovefllg t<>:cfe~
of the flag group when the specified condition occurs. For example a bisk .
OS_FLAG_WAIT_8ET_ANY + OS_FLAG_CONSUME to wait for the setting:pf;any
specified flag bit and the flag bits are automatically reset (cleared) when.the coJ'ldh{oh ·
occurs. If the priority of the task waiting for the specified bit pattern is greater than
that of the priority of the task signalled the availability of the specified bit pattern, it
is preempted. If the event :flag bits satisfy the conditions specified by the ~ask, the task
is readied. If the event :flag bits don't satisfy the conditions specified by the task, at
the time of calling this function, the calling task is blocked and it is put in the. event
flag wait list queue associated with the event flags group. A task can wait until the
specified flag pattern arrives or till a timeout occurs. The timeout value for waiting
can be specified in the 'timeout' argument of this function call. The 'timeout' value is
specified in terms of clock ticks. It can take values ranging from Oto 65535. A value
l
of Oindicates wait until the specified event flag condition occurs. ··
: Used for che~kjng the pccJ11Ience o.fa S,pecified flag bit pattern in the eyeIJJ
in
'.:similar to OSFlagP~n}!0 fooctioniug but differ in the way it ·ope~at~s:'
task:to check:wliether'.ih~ speci~ed bit pattern is ay!tilable. Unlike OSFfagI:t
calling task is not blocked ('Pended') if the specified flag event is notocct1i:red,t

t Please refer to the MicroC library reference manual i()f the 1)::!rametcr dcta:ls of each fonct1011 call
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-II RTOS

OSFlagPendGetF/agsRdy() Retltrns the flag value that made the task ready from blocked state.
psJ;iagQiie_zy() .· · Retriey~§ .tb.e Ye.~tft.ilg~ j.n·. · tlie ~yent flag~:gr9µp',i.J:~eJ1("
\:·<:\a\
' - -"-;,_Jb-f{:~
· r6m1-hith'es~t ··ev~rif&h?"\if.. .... ·• fc ..
OSFlagNameSetQ Associates a name with the specified event flag group. The name is passed as a
character pointer. This function is mainly used for associating a name with a resource
for debugging purpose.

OSFlagDel0 Deletes an event flags group. Option for specifying whether the event-flags group
needs to be deleted immediately or only when the pending operations on this event
flags group are over. Proper care should be applied in the usage of this function. There
are possibilities for tasks to access a deleted event flags group. This may result in
unpredicted behaviour.
The following code snippet illustrates the usage of event flags.
I I* *1'.*
. '· - - '
,
***if.**********************'****
·. -~-- ;
**·"*·*'2,*
" "
*** * *** **** * ** * * * * k ~ * * *,:**
-.
.
#include ~includes.h>

• ;)Define Ta;k :(Os for First Task, ']:ask ·r\itid<tas;k 2

#define. TABKr FiisTYo' 1
, #define TASK=l_}D '2
#define TASK_.:.2 ..ilD 3

.·. /!Define Task Pri6rities for '.·F;L,tsl:. Task, . Tast 1 · ,.and Task 2 .
. #define TASK :?1Rs£<&RIQ 10
t'deffrie TASK?l .pfio 12 ·.
#define TASK 2 PRI(f 11

//Set the default stack size for all tasks

#d~fine TASK STK SIZE 1024

//Define stack size for tasks

OS_STK TaskFirstStk[TASK STK SIZE]; // First task's stack
OS STK TasklStk[TASK_STK SIZE]; // Task l's task stack
.OS STK Task2Stk [TASK_ STK _SIZE]; // Task 2's task stack

//Define Even Flags Group pointer for th~ mutex

OS_FLAG_GRP *StatusFlags;

void main (void)

//Initialize MicroC OS
OSinit();

,//Create the first task.

OSTaskCreateExt(TaskFirst,
 Introduction to Embedded Systems ·

(void *)0,
&TaskFirstStk[TASK_STK SIZE - l.],
TASK_FIRST_PRIO,
\ TASK_FIRST_ID,
&TaskStartStk[0],
TASK_STK_SIZE,
(void *) 0,
,OS TASK OPT STK_CHK);
. I I Start,. rimlt:;.itasking
osst·art
.. .(). ;:
)
,: .•;·,
"A':~•.)

I I*~**;* *'I,;**~******************************·*****: **~4'~_:ir *';, i'-1<'1::::1r;r:** * * ** .

:/-(JI1\pl~mentatfon of Tas'kFirst
·,;;aid TaskFirst (void *args) \
{
//Variable for holding function return values
INT8.U err;
//Initialize statistics. task
OSStatini t () ;
//Create the event flag group with all flags in rest:!e state.
StatusFlags OSFlagCreate(0x00, &err);_
I /Create Ta_skl
OSTaskCreatetxt(Taskl,
(void *) 0,
&TasklStk[TASK_STK sizE - l],
TASK 1 PRIO,
TASK_l_ID,
&TasklStk[0],
TASK STK SIZE,
(void *) 0,
OS TASK OPT STK CHK);

//Create Task2
OSTaskCreateExt(Task2,
(void *)0,.
&Task2Stk[TASK_STK SIZE - l],
TASK 2 PRIO,
TASK 2 ID,
&Task2Stk[0J,
TASK_STK SIZE,
(void *) 0 1
OS TASK OPT STK_CHK);
while (1)
{
//Do Nothing. Simply sleep for one timer tick
OSTimeDly(OS_TICKS_PER SfC);
}
}
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-11 RTOS

//*******************************************************************
//Implementation of Taskl
votd Taskl'(void *a.rgs)
{
/ /Vari~ble for. hol,ding function return yalues
INT8U err;
while ·(1)
,. ,· , i .. ~- ·--·" '~;

{ .. :. .;. ·. '
. .. . :' ....
I/Execifnr:the?ta's.k, specific. 'det•atis ·

j 1~ifJJJi~:·~~::f[~~ 2,:,;_:,~-j~
OSFlagPost,(Statu~F&ags, Ox OS;.. &J~t-tl
//Rest. of' the .. task :· . . .
I!.·.... :...... · .... :···"•.... ··_ .........,.. '. :·>.. ;······... ·•.·· ...·
I! ..... ·.-......... _.. : ...: .. '·.... ·:-.......:· .. ·--., .. ··........ ·... _.·... ·
}
}
, ,_;-•'?';,.

>11;;:;i~~;: ~1r~;ti::~~'.···,~
'; \/oict'··Tb.sk2Jvoid *args)
****

f;;1":\! :.·"~-.::' i ~ . : ,•:--~ • ,,.,_,,

~~tr
/1»:aifi~blet for holding

j : /·
.i /Execute ·.the task. speclfk deta'ils
.11 ..·_.'i\.· ....·.......................... ·•·:- . :;_· . ·. ;· .........-.. '.. -::,
I( ...... · .......... ·. ............................ _.... _.._. .........·_ .. ,
//Wa'it for the signaling bf either flag bli:'7 0 or 2
OSFlagPend(StatusFlags, OS FLAG WAIT SET ANY,0, &err);
if (OS NO_ERR ·err)
{
//Find out the flag bit value readied the task and print it
err= OSFlagPendGetFlagsRdy(};
printf("The Flag state readied the task is %x", err);
}
else

//Rest of the task

11 ................................................................................
// ......................................................... , ...................... .
}
}
}

The sample application creates a main task TaskFirst with priority 10, which creates an event flag
group SratusFiags and two tasks namely Task] (with priority 12) and Task2 (with priority 11). Task2
 '\ ;'E(
> ;fi:},

Introduction to Embedded Systems

requires the signalling of two flags to continue its execution. At some point of execution Task2 waits for
the occurring of any one of the specified event. Task] sets the flags at some point of its execution. Since
the priority of Task2 is higher than that of Task], Task2 preempts Task] when the signalling of event flag
occurs. Task2 also prints the event flag bits value which made Task2 'Ready' for execution.
The flag based task execution synchronisation is the best choice for synchronising the execution of
cooperating tasks which requires the occurring of a particular sequence of operation for completion. A
typical example is a 'Smart Card Reader' interfaced with a PC. The card reading operation can be con-
trolled from.an application running on the PC. Obviously there are two tasks running in the Smart Card
Reader Device. Task 1, 'The Communication task', checks the serial port or USB port to receive the
commands from PC. The second task 'The card Reading task' waits until a command is received from
the PC, to continue its operation. The 'Communication task' can inform the 'Card reading task' that a
command is received, by setting a flag in the event flags group.

11. 2. 6 Timing and Reference

The 'Clock Tick' acts as the time source for providing timing reference for time delays and timeouts.
'Clock Tick' generates periodic interrupts. The clock ticker interrupt should be enabled for handling the
clock ticks. The clock tick ISR (OSTickISR(void)) calls the function OSTimeTick0 to service the clock
tick interrupt. The OS_TICKS_PER_SEC configuration parameter should be set properly for the proper
functioning of the system timer. It defines how many clock ticks are there in one second. It depends on
the clock frequency of the target board. The functions which relay upon OSTimeTick0 are summarised
in the table given below.

. .

11. 2. 7 Memory Management

MicroC/OS-II supports runtime memory allocation and de-allocation on a need basis. The memory is
divided into multiple sectors (partitions). Each sector is further divided into blocks. Each block holds
fixed bytes of memory. Figure 11.1 illustrates the same.
Each partition contains a minimum of two memory blocks. The block size is uniform throughout a
partition. Each memory partition associates a memory control block (MCB) with it. The following table
gives a snapshot of various function calls supported by uC/OS-II for memory management.

t Please refer to the MicroC library reference manual for the parameter details of each function call.
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-II RTOS

Partition 1 Partition 2 Partition n

(Fig:·11. 1) Memory partitioning under Micro C/0S-II

'" . ' n 1 .
e,:1NT8U*~rr) ' ,;r1blks.spe
~sthe siz

Releases th~ip~~lliid&em~ry block to the memo

a pointer to theinemory partition control block which is
creating the memory. partition and pblk is the poi11terJo.
block to be released. Returns the code OS_NO_ERR if
block de-allocation is success.
uery(OS_MEM *pmem, Retrieves the i '· n:~bout a memory partftf
.DATA *pdata) ~:ttµre of type OS_)JEM_:.
I gettinlf mf()iii:i' ,. start address of me~o

I
of memory'bkr9 ·. Int . ition, size of a me~tl
used memoryh!i~iss,>·nHmber of free memory bld~~r
OSMemNameSet(OS_MEM *pmem, Associates a name with the specified memory partition.·
qhar *pname, TNT8U *err) passed as a character pointer pname. This function is ma'
associating a name with a resource for debugging pu!J)~~e
i OYPrfenilfameGSet(OS- MEAf *pmem, Retrieves the 11aµk·associated with the specjfi~
L~6tw.tp~dme, INT8U *err) The name is retfie\'yd,i~ ad1aracter pointerpn~;
f,~,t ·•,h.,' ' argument to this:f,,m.ctr6h: This function is nrainlfcu
a name with a res6iirce:for debugging purpose. ' · ··
 Introduction to Embedded Systems

11.2.8 Interrupt Handling

Under MicroC/OS-II, each interrupt is assigned an interrupt request number (IRQ). The actions cor-
responding to an interrupt is implemented in a function called Interrupt Service Routine (ISR).The IRQ
links to the corresponding ISR. The ISR contains code for saving the CPU registers and restoring it back
when returning from ISR. The register saving instructions are processor dependent and they are usually
coded in processor specific Assembly language. The interrupt service routine can be implemented in C
function, provided the cross compiler supports mixing of assembly code with 'C' (Inline assembly code
for saving and restoring CPU registers). If the cross-compiler doesn't support inline assembly codes,
the only option left with is code the ISR in assembly®. MicroC/OS-II supports nested interrupts with
a nesting level of 255. The interrupt nesting level is kept tracked by the counter OSlntNesting. The
function OSlntEnter0 informs the MicroC/OS-II kernel that an ISR is being processed. This function
contains the code for keeping track of nested interrupts by incrementing. the counter OSlntNesting.
When an interrupt processing is over, it is notified to the MicroC/OS-II kernel by calling the function
OSintExitQ. It contains code for decrementing the interrupt nesting counter OSintNesting and task re~
scheduling if a high priority task is 'ready' for running at the end of servicing the last nested interrupt.
The ISR returns to the interrupted task if there is no high priority task 'ready' for running at the time of
execution completion. If there is a high priority task 'ready' for running at the time of ISR completion,
the execution is not returned to the low priority task which is preempted by the ISR. Instead it executes
the high priority task. The implementation of an ISR is illustrated below.

.,(p;;~:~l~1:;~:t:i\1X~J4;£~t ·•,~,'-'···· ··'··*••..... ••

"'"'' ,, .,,

**;,;.**,**i->:**
~,·.vpi&,\1nl:.E!'L:iupt;':~YZTI)terr:-up;t"( .;Lnt:. ;vec;;tor)

~~E~t}t~:~~u;tioDs .~; ~~;,;(~USHI CPU (egiSt€rs

1i±;!:r J:ntJifupt \1e1ti'ig.

OSintEnter(};
I /Ex.ecut:.e th.e ISR specific code
// .................................................................................
11 ................................................................................ .
//Return from ISR
OSintExit (};
asm
//Assembly instructions to retrieve (POP) CPU registers
// ............................................................................... .
// .................................................................................
- endasm
}
}

The keyword interrupt identifies a function as Interrupt Service Routine (ISR). The parameter vector
specifies the interrupt vector address corresponding to the ISR. It should be noted that an ISR neither
takes and nor ren1rns any variables. All CPU registers are saved (PUSHed) to the stack of the task which
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-11 RTOS

is interrupted by the ISR. However certain processor architecture like Motorola 68030 requires a sepa-
rate stack for ISR.

11.2.9 The MicroC/OS-11 Development Environment

Various processor manufacturers, who develop the MicroC/OS-II port for their product, may also sup-
ply an IDE for MicroC based development. The Nios® II IDE from Altera (www.altera.com) is an IDE
supplied by Altera for their Nios® II family of processors. Some third party developers also provide
IDE for MicroC/OS-Il development for various processor architectures. The Micro-IDE is an example
for a 3rd party development tool. It supports Micro C compilers 6808, 6809, 6811, 6812, 6816, AYR,
8051/52, 8080/85, 8086 and 8096.

Summary
•y •

✓ VxWorks is a POSIX compliant popular hard reaJtime, multitasking operating system from Wind RiyifStst~nil::,;
The kert1ei ofVxWQrks jipopularly known as wind . · . .:.i . ···.· ..· . ·;. . · . . · · < '.t:'W:,1.:';;,'.itfi

r✓ Under Vx W6rk,skemel, thet~~ks mayi3el11 one 9fthe primary.states 'READY;: ·,~END', 'DELAY', '.~tisp~wi}:
pr "a specific,c6hil{ihaJ9n bfit:at ~y given p◊irit,clftime •· · .· · . . . ' 1 \ '·/;.,' / ' '
.✓ VxWorks supports prioritykvels from Oto 255,with 0 being the highest priority,,for tasks.VxWo'rks,\i~~?~~Je(:;
implem~nts· the·pre-emptive prior1fy oased•scheduling of t~sld with.·Rbtnd tbbtn·sc4e:duling'l6r:;pq9J1,fy.i'.
resolution among equal priority tasks . · . ., /:';,,
✓ The kernel functionalities of 'VxWorks' is also implemented as tasks.and they are known as system ta~les:{Jlfe';

I root task tUsrRoot is the first task executed by the ~<::p.t:dule~:dhe function usrRootO is th~ entry pointtoi:t~(s:;:
task

Remote.Procedure Call (RPC) and signals

· ·· ·

··
·

.. ·
·

·
·· · ': \.f'. ),
✓ Vx Works implements Inter Task (;Orm:nllllication thr~mgh shared memory, message queues/pipei, i~p:c~tt~j:,.
· ·· . > ::'..:l:Vr't{,.t::t
✓ VxWorh' kernel follows a single linear.address sp11ce for tasks. The data can be shateg in theforrn.o£g!Q~iL
variable, linear buffer, linked list and ring buffer , · .• · · ,: · . ·c:\;t>;"s:
✓ VxWorks implements mutual exclusion policies in three different ways namely; Task Locking (Disabling task
preemption), Disabling Interrupts, Locking resource with semaphores •·.· · ·

I ✓ VxWorks supports three types of semaphores namely; Binary semaphore, counting semaphore and mutual
exclusion semaphore
✓ Under VxWorks kernel, Interrupt Service Routines (ISRs) run at a special context outside any task's context. A
separate stack is maintained for use by all ISRs

I
✓ The watchdog timer interface provided by VxWorks kernel can be utilised for monitoring task execution. The
watchdog timeout is handled as part of the system clock ISR. User can associate a 'C' function with the watchdog
timeout handler
✓ Wind River Workbench is the development environment from Wind River Systems for VxWorks development
✓ MicroC/OS-11 is a portable, ROMable, scalable, preemptive, real-time, multitasking kernel from Micrium In9
✓ MicroC/OS~II follows the task based execution model and each task is implemented as infinite loop. Under
MicroC/OS-11 kernel, the tasks may be in one of the states Ready, Running, Waiting, Interrupted at a given point
of time
✓ MicroC/OS-11 supports tasks up to 64. Out of this 8 are reserved for the MicroC/OS-Ilkernel. Each task will have
a unique task priority assigned. No two tasks can have the same priority
 Introduction to Embedded Systems

✓ The OS kernel initialisation function OSinitQ is the first task executed by MicroC kernel. It initialises the different
OS kernel data structure and creates the Idle task OSidle0. The Idle task is the lowest priority task undert1rb·
MicroC/OS~II kernel and it is executed to keep the CPU always busy when there are no user tasks to execut~; ,;
✓ MicroC/OS-ILexecutes a statistical task with priority OS_LOWEST_PRI.O -1 in every second to capture;tli~1:•
percentage9f CPU usage. · · ~· ··
✓ The MicroC/OS-II supports preemptive priority based scheduling. Each task is assigned a unique priority ranging
. from·o to>63 :With 0,being the highest priority leveL The four highesrpriorities·(0 to 3) and the four :1o\V~st/,
pripri~ies (63tP~QS..:.:EOWEST_:PRIO 3) are reserved for the kernel · ·
· ✓- J11e Mipi~Q£QS-:II.ken1el starts execu(ingthe.first available 11ighest pgoritytask a11d aJask re~schedulingl1Jf ·
whin:eyerl?t~~J<::enters the 'Waiting' state due to the invocation of sy~tern calls, and whenever an ··
oc2tirs,;tbetasktare ~escheduled upon return from theJnterrupt Service Routine... . .. . •. ·.
✓ J'he Mic,racl6s-ukemel supports Inter Task Comrnul)ication tliroµgqmiilbci arid m~ssag~ queues.
✓ The MicroC/OS-II kernel implements mutual exclusion through disabiing msk s~heduling, disabling int
using semaphores and events • . .• . . · •.· ...
✓ MicroC/OS~II supports two different types of semaphores, n?;mely, counting semaphore and mutual exc.
semaphore (mutex) . . . •. :. , ., . · ··· . ,:.·
✓ UnderMicrqC/0S-II, the 'Clock Tick' acts as the time source forpn)vid~ngJi,rhiQg ieferen:cefo(ti;m,e de.la;
tinieo~ts.'ClpckTick'gerieratesperiodicinterrupts .··. ,. ;' :·l· . .•.•\ . ··· !;)
✓ Under Mic:;r6G/OS-II, each interrupt is assigned an•futerruptRe_qu.~~f#l!lPoe:)(IRQ}. 'I:J;ie:~cµqti~ corr,~@.
to an integupt is implementect" in a function. Called Interrupt Service Routine (ISR). The IRQ lirikf
correspondi!lg ISR · · . · ·
✓ The Micro-IDE is an example for 3 party developmenqool for MicioC/OS-II
rd

c~) Keywords ]

VxWorks Apopular hard real-time, multitasking operating system from Wind River Systems
wiqd The kernel ofVxWorks
Task ·scheduling The act of allocating the CPU to different tasks
Kernel A set of services which forms the heart of an operating system
Messag~ Queue An inter-task communication mechanism used in VxWorks. It comprises queue for sending ·
and receiving messages .
Pipe A message queue based IPC mechanism under VxWorks
Socket The mechanism utilised by VxWorks to communicate between processes running on different

I
targets which are networked and for executing a procedure (function) which is part of another
process rnnning on the same CPU or on a different CPU within the network
Signals A fom1 of software event notification based Inter Process Mechanism supported by VxWorks
Mutual Exclusion A binary semaphore implementation under VxWorks kernel, which implements mechanisms
Semaphore to prevent priority inversion
Watchdog Timer A special timer implementation for monitoring the task execution time and triggering
precautionary actions in case the execution exceeds the allowed time
Tornado® II The VxWorks development environment from Wind River Systems
MicroC/OS-11 A portable, ROMable, scalable, preemptive, real-time, multitasking.kernel from Micrium Inc
Mailbox An IJ:>C mechanism supported by MicroC/OS-II kernel, for exchanging a single message
between two tasks or between an ISR and a task

l
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-11 RTOS

Objective Questions
1. Which of the following is true about VxWorks OS
(a) Hard real-time (b) Soft real-time (c) Multitasking (d) (a)and(c)
(e) (b) and (c)
2. A task is waiting for a semaphore for its operation. Under VxWorks task state tenninology, the task\is said to be in
- - - state , ·
(a) READY (b) RUNNING (c) PEND (d} SUSPEND
(e) None of these
3. Under VxWorks kernel the state of a task which is currently executing is changed to SUSPEND. Whiqh of the
following system call might have occurred?
(a) taskSpawnQ (b) taskActivateO (c) taskSuspendO (d) msgQSendO
(e) None of these
4. Under VxWorks kernel the state of a task is SUSPEND. Which of the following statement is true?
(a) It is a new task created with system call tasklr,itQ and not yet activated
(b) It is a new task created with system call taskSpawnO and not yet activated
(c) The task is suspended by the system call taskSuspendO
(d) Execution of the task created some exception ,
1
(e) All of the above (t) Only (a), (c) and (d) (g) Only (b), (c) and (d)
5. Which of the following is not part of a task's context under standard VxWorks kernel?
(a) Program counter (b) CPU Registers (c) Memory address space (d) Signal Handlers
(e) None of these .
6. Under VxWorks kernel, executing the system call kernelTimeSlice (0) produces the impact
(a) The scheduling becomes pre-emptive priority based with Round Robin for Priority resolution
(b) The scheduling becomes pre-emptive priority based with no priority resolution
(c) The scheduling becomes Round Robin (d) None of these
7. What is the priority level supported by VxWorks for tasks?
(a) 10 (b) 255 (c) 256 (d) Unlimited
8. Which of the following is(are) true about the system call taskDeleteQ
(a) Tenninates a specified task (b) Frees the task memory occupied by stack
(c) Frees the memory occupied by the task control block
(d) Frees the memory allocated by the task during its execution
1 (e) All of these (t) Only (a), (b) and (c)

I 9. Which is the first task executed by VxWorks kernel on a system boot-up?

(a) tNetTask (b) tUsrRoot (c) tRlogind (d) tWdbTask
10. Which of the following is not an IPC mechanism supported by VxWorks •

I (a) Shared memory (b) Message queue

are perfonned by the default exception handler service?

(a) The task caused the error is suspended
(c) mailslot

(b) The state of the task at the point of exception is saved (c) Initiates a system reset
(d) Sockets
11. While executing a task under Vx Works kernel, an address error exception occurred. Which of the following actions

(d) All of these (e) Only (a) and (b)

12. Which of the following is not a mechanism supported by VxWorks for Inter Task Synchronisation?
(a) Binary semaphore (b) Test and set (c) Counting semaphore
(d) Mutual ·exclusion semaphore
13; Which of the following is true aboutthe scheduler locking based synchronisation under VxWorks kernel?
(a) May lead.to unaccep 1able real-time response (b) May increase intenupt latency
(c) Both of these (d) None of these
 Introduction to Embedded Systems

14. The mutual exclusion semaphore under VxWorks kernel is a type of

(a) Counting semaphore (b) Binary semaphore
15. The mutual exclusion semaphore prevents priority inversion by
(a) Priority ceiling (b) Priority inheritance
16. Which of the following is true about Interrupt Service Routine under VxWorks kernel
(a) It runs in a separate context
(b) It runs on the same context as that of the interrupted task
(c) It depends-On the processor architecture in which the VxWorks kernel is running
(d) None of these
17. Which of the following is true about the stack implementation for ISR under VxWorks?
(a) All ISRs share a common stack
(b) The ISR uses the stack of the interrupted task
(c) It depends on the processor architecture in which the kernel is running
(d) None of these
18. What is the priority levels supported by MicroC/0S-II kernel
(a) 64 (b) 56 (c) 256 (d) Unlimited
19. Which of the following is true about task scheduling under MicroC/0S-II kernel
(a) Priority based pre-emptive scheduling
(b) Priority based non-preemptive scheduling
(c) Round Robin
(d) Pre-emptive priority based with Round Robin for priority resolution
20. Which of the following is not true about tasks under MicroC/0S-II kernel
(a) Supports multiple tasks with same priority (b) ISRs are allowed to create tasks
(c) The stack can be specified as either upward growing or downward growing
(d) All of these (e) Only (a) and (b) (f) Only (a) and (c) (g) Only (b) and (c)
21. Under MicroC/OS-II kernel changes its state from 'RUNNING' to 'WAITING', which of the following conditions
might have invoked this?
(a) The task attempted to acquire a shared resource which is currently in use by another task
(b) The task involves some 1/0 operation and is waiting for I/0
(c) The task undergoes sleeping
(d) The task is suspended by itself or by another task
(e) Any one of these (f) None of these
22. Which is the MicroC function responsible for initialising the different OS kernel data structure
(a) OSJnitQ (b) OSStartQ (c) OSJdle0 (d) None of these
23. Which of the following is not an IPC mechanism under MicroC/OS-II kernel
(a) Message queue (b) Mailbox (c) Pipes (d) None of these
24. Which is the function call used by an ISR to indicate the occurrence of an interrupt to the MicroC/OS-II kernel
(a) Interrupt (b) OSJntEnter (c) OSJntExit (d) OSlntNesting
25. Under the MicroC/OS-II kernel, the !SR for normal processor architecture makes use of which stack?
(a) Stack of the Interrupted Task (b) Separate stack
(c) A mix of a separate stack and stack of interrupted task
(d) ISR doesn't use any stack

Review Questions
1. Explain 'task' in 'VxWorks'. context? Explain the different possible states of a task under VxWorks kernel.
2. Explain the state transition.under VxWorks kernel with a state transition diagram. Give an example for the scenarios
. for each state transitions.
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-11 RTOS

3. Explain the task creation and management under VxWorks kernel.

4. Explain the difference between tasklnitO and taskSpawnO system calls for task creation under VxWorks kernel.
5. Explain the task scheduling supported by VxWorks kernel.
6. Explain the priority based pre-emptive· scheduling with Round Robin scheduling for priority resolution under
VxWorks, with execution diagram for the following:
(a) There are 3 tasks Tl, T2 and T3 with priority 15 READY to run and the execution time for the tasks are 20,
15 and 20 Timer Tick respectively ·
(b) The Time slice for Round Robin scheduling is 5 timer ticks
(c) The scheduler selects the tasl5:-s in the ordi;r Tl,T3,T2 for Round Robin execution
(d) After 7 timer ticks, task 4 with priority _14 and execution completion time 10 becomes 'READY'
7. Explain the exception handling mechanisms for tasks and interrupts under VxWorks kernel
8. Explain how a task can be made safe from unw.anted deletion underVxWorks kernel, when it is holding a system
resource
9. Explain the kernel services ofVxWorks
10. Explain the different types oflnter Process-Communication Mechanisms supported by VxWorks
11. Explain the implementation of a two-way message queue between two tasks under VxWorks kernel, with a block
diagram
12. Explain the different mutual exclusion mechanisms supported by VxWorks. State the relative merits and limitations
of each
13. What is semaphore? Explain the different types of semaphores supported by VxWorks
14. Explain how a mutual exclusion semaphore prevents priority inversion in task execution under VxWorks kernel
15. Explain the different system calls for wind message queue creation and management under Vx Works kernel
16. Explain the different system calls for POSIX standard message queue creation and management under VxWorks
kernel
17. Explain pipe based IPC implementation under VxWorks kemel. How is it different fonn the message queue based
IPC?
18. Explain the 'Signals' based IPC implementation-under VxWorks kernel
19. Explain the interrupt handling mechanism under VxWorks kernel
20. Explain bow a 'C function' can be used as the ISR for an interrupt under VxWorks,
21. Under VxWorks it is required to mask interrupts with priority less than 2 while allowing the other interrupts to be
serviced. Explain how it can be achieved?
22. Explain the watchdog timer operation under Vx Works kernel
23. Explain the time delay generation under Vx Works kernel
24. Explain the different possible states of a task under MicroC/OS-II kernel
25. Explain the state transition under MicroC/OS-II kernel with a state transition''diagram. Give an example for the
1 scenarios for each state transitions
I 26. Explain the task creation and management under MicroC/OS-II kernel
27. Explain the task scheduling supported by MicroC/OS-II kernel
28. Explain the kernel functions and initialisation under MicroC/OS-II kernel
29. Explain the role ofldle Task under MicroC/OS-II kernel
30. Explain the different types oflnter Task Communication mechanisms supported by MicroC/OS-II kernel
31. Explain the different mutual exclusion mechanisms supported by MicroC/OS-II kernel. State the relative merits
and limitations of each
32. Explain the different types of semaphores supported by MicroC/OS-11 kernel
33. Explain the event based task synchronisation under MicroC/OS-II kernel
34. Compare the signal based synchronisation under VxWorks and event based task synchronisation under MicroC/
OS-II kernel
35. Compare the VxWorks and MicroC/OS-II kernel
36. Explain the time delay generation under MicroC/OS-II kernel
37. Explain the dynamic memory management under MicroC/OS-II k;erne'i
38. ·Explain the Interrupt handling mechanism supported by MicroC/OS-II kernel
 Introduction to Embedded Systems

Lab Assignments
1. Write a VxWorks multitasking application to create two tasks as.,per the following requirements
(a) The stack size for both the tasks are 2000
(b) Priority for both the tasks are 100
a
(c) Task 1prints the message "Hello from Task l" continuouslyW,ith delay of 500 timer ticks between successive
printing
(d) . Taskc2 printsJhe:message ':Hello-from Task 2" continuously with a·delayof 500timer ticks between succes~ive
·printing· .
. 2: ,,.,,0\Vrite :a:VxWorks multitasking application ti:) retrieve:ahd change' the "PbSIX>priority assigned tcHhe ,filsks as:per
the following requitenients . . . . . . . . .
. (a) Create two tasks with names "Taskl" and "Task2" respectively. The'sta6k size for btith the tasks a're·2000
{b) ·prfo~ity for both,the tasks are initiaJly' set at 100 ·.. .,
. ' (C) Taskl is ~pawned first and tlietiTask2 ·'
(d) Taskl retrieves its priority and prints it on the console~d then changes it to current,priority-l;ifthe'ttlrrx.Qt
· priority is ah even number, else changes to priority+ 1 . '"-~
(e) Task2 retrieves its priority.and
",/ ,::.-v ,...
prints it, on they console and then changes it to currentpriority-1, if the current
priority is an even nuffiber;'else changes to priority+ I · , . - .
(f) ·Use Ro~d Robini~cheduiingwith tittle slice20:tipierlick'fgr ptiodfy resolution . . . .· .· .·. . < , · .·
3. An embedded appli6'atiqn .fu'volves re'adilig .data from' an ~alog \o Digital Cohv~iter.· The )illC 'inqicaf~sJlie
availability of data Sy a:s§ertilig thei·qferruptlliie V:1uch is'cbnnected to the proce'ssor' ofihe systetri.'The'fu.(errupt
vector for the external interrupt line to 'which 'the ADC is interfaced' is 0x0003. The JSR for the external
, . ' , ' I . , ,·~ .,· • . {· , ,,: "•" \''. • •t_
iiiterrupt
'·•' ",,»:'· ···:~_~· ,_/_'
·~, , _ . : ,

reads the data and stores it in a shared buffer of sii,e 512""bytes·. the tec~ived data is processed by.a-task.Jb,eJask
reads the data and prints it on the console. The com:munication betwe.en the IS.R and task is synchronised ~iuik:a
binary semaphore. The task waits for the avi!ilabHity of the binaty'sefulphord and, the ISR gig11als !~~; !l;~i\abmt,y
of the binary semaphore whe11 an interrupt dtcurs~and the <lat~ is read from the device: Write anappiicatio~fo
implement this requiremenhmder VxWorks' kehlel . ,, ' . . . ! '•' • ' ·. '

4. Re-write the message queue example given undei the Inter Task Communication section ofVx,Worl.<s forpostirig
the message as a high priority message
5. Create a PO SIX based message queue under VxWorks for communicating between two tasks as per the requirements
given below
(a) Use a named message queue with name "MyQueue"' .
(b) Create two tasks (T11skl and Task2) ,vith stack size 4000 and priorities 99 and 100 respectively
(c) Taskl creates the specified message queue as Read Write and reads the message present, if any, from the
message queue and prints it on the console
(d) Task2 opens the message queue anp posts the message "Hi From Task2"
(e) Handle all possible error scenarios appropriately
6. Implement the above requirements with 'notification' based POSIX message queue (Hint: Use signal for handling
the notification)
7. Write a VxWorks application as per the requirements given below
(a) Three tasks with-names Taskl, Task2 and Task3 with priorities 100, 99 and 98 respectively are created witli
stack size 2000
(b) Taskl checks. the availability Qf a binary semaphore 'binarySem' and if it is available, it prints the message
"Hi from Taskl'' 50 times and then releases the binary semaphore and completes its execi+tion
(c) Task2 prints the message "ffi from Task2" 50 times and completes its execution
(d) Task3 che<:ks the availability of a binary semaphore 'binarySem' and if it is available, it prints the message
"Hi from Task2" 50 times and then releases the binary semaphore and completes its execution
- I -
 An Introduction to Embedded System Design with VxWorks and MicroC/OS-II RTOS .

.e:
. ~aJihg' •,.. <.,/
. . ~f . t~ hj!esJmdf;_ .:·,9, . , .. ·"· ; , . · ·•· · •· ./ .,, .1:t . .•i :r:·.
t\~1:a,' Task,tdisplays .the m~eyefageJqata 'i8.e¢eived *,".and appends .the. rece,ived O~~

~i~,~~Jt~~,M~~!ll•~~~hl~h),.Jft,n,_c!,i~ b e ~
. . , . •.
1
. .. ~fstein timer iriterrµpt, and displaying the time on the fidt 1!11:e 9f t~e L~D in HH:M~f
••

S$ fof1llat. l'he P,is,play ,shoµld qe ceptralised to the first line with packing with blank chan,tcters on both
sidfs . ' . . f. 'HFi:M1'1:SS '') . . .'
(d) Task2 is created with stack size 512 bytes and priority 10
(e) It is assu·med thattlle fupttion 'for initialisinfthe LCD, L.CDlnitO is avaiJabk. You c~n use a dummy function
· call LtDinitO to indicate the initialisation ofthe LCD. Similarly adummy function LCDWrite(x, y, char) is
also available for displaying character on the LCD'at position x,y. x = 0 for line 1 and 1 for line 2. y varies
from Oto 15
(f) Task3 displays the message "HAVE A GREAT DAY" on the second line of the LCD if there is no data
reception activityjnprogress.,Task3 is created with stack size 512 bytes and priority 11
{g) Eaph task..
should:contain self-delaying foi.
a period
•..
of 5 timer
.
ticks toI give another t~ska chance to execute
'(h). Wqen the systep1;starts up,.th,e c~ent time i~ displayed on the-first hne and ¢.e'message "HAVE A GREAT
DAY:' is displayed on,the,secp]ld1ine of th;LCD
(i) The ·learning objective offhis applfoatiop ts the usage of semaphore under MicroC/OS-II kernel for enforcing
. mutual exclusion in shar~drbsourcp a.ccess .
 Integration testing of the embedded hardware and firmware is the immediate step following the embed-
ded hardware and firmware development. Embedded hardware and firmware are developed in various
steps as described in the earlier chapters. The final embedded hardware constitute of a PCB with all
necessary components affixed to it as per the original schematic diagram. Embedded firmware repre-
.· sents the control algorithm and configuration data necessary to implement the product requirements on
the product. Embedded firmware will be in a target processor/controller understandable format called
machine language (sequence of ls and Os-Binary). The target embedded hardware without embedding
the firmware is a dumb device and cannot function properly. If you power up the hardware without
embedding the firmware, the device may behave in an unpredicted manner. As described in the earlier
chapters, both embedded hardware and firmware should be independently tested (Unit Tested) to ensure
their proper functioning. Functioning of individual hardware sections can be done by writing small utili-
ties which checks the operation of the specified part. As f1+r as the embedded :firmware is concerned, its
targeted functionalities can easily be checked by the simulator environment provided by the embedded
firn1ware development tool's IDE. By simulating the :firmware, the memory contents, register details,
status of various flags and registers can easily be monitored and it gives an approximate picture of
"What happens inside the processor/controller and what are the states of various peripherals" when the
firmware is running on the target hardware. The IDE gives necessary support for simulating the various
inputs required from the exte~al world, like inputting _data on ports, generating an interrupt condition,
 Integration and Testing of Embedded Hardware and Firmware

etc. This really helps in debugging the functioning of the firmware without dumping the firmware in a
real target board.

~i~i,ri~?n~~;.t~•
~,',.:_-i-_\,>,;;,,: ,~) '.'.:~;~ :,

Integration of hardware and firmware deals with the embedding of firmware into the target hardware
board. It is the process of 'Embedding Intelligence' to the product. The embedded processors/control-
ters used in the target board may or may not have built in code memory. For non-operating system based
embedded products, if the processor/controller contains internal memory and the total size of the firm-
ware is fitting into the code memory area, the code memory is downloaded into the target controller/pro-·
cessor. If the processor/controller does not support built in code memory or the size of the firmware is
exceeding the memory size supported by the target processor/controller, an external dedicated EPROM/
FLASH memory chip is used for holding the firmware. This chip is interfaced to the processor/control-
ler. (The type of firmware storage, either processor storage or external storage is decided at the time of
hardware design by taking the firmware complexity into consideration). A variety of techniques are used
for embedding the firmware into the target board. The commonly used firmware embedding techniques
for a non-OS based embedded system are explained below. The non-OS based embedded systems store
the firmware either in the onchip processor/controller memory or offchip memory (FLASH/NVRAM,
etc.).

12 .1. 1 Out-of-Circuit Programming

Out-of-circuit programming is performed outside -
the target board. The processor or memory chip into
which the firmware needs to be embedded is taken
out of the target board and it is programmed with '· .,

, JJ.';::<,<;-~'',,;·:--,¥, '
the help of a programming device (Fig. 12.1). The
programming device is a dedicated unit which con-
tains the necessary hardware circuit to generate the
programming signals. Most of the programmer de-
vices available in the market are capable of program-
1
ming different family of devices with different pin
i outs (Pin counts). The programmer contains a ZIF
? socket with locking pin to hold the device to be pro- ( Fig. 12.1) Firmware EmbeddingTool~Device
.t Programmer: LabTool-48UXP)
grammed. The programming device will be under the
r

I
(Courtesy of Burn Thchnology Limited
control of a utility program running on a PC. Usually www.burniec:coin &Advaniech Equipment Corp
e the programmer is interfaced to the PC through RS- www:aec.com.tw)
!-
232C/USB/Parallel Port Interface. The commands
:s to control the programmer are sent from the utility program to the programmer through the interface_
d (Fig. 12.2).
s, The sequence of operations for embedding the firmware with a programmer is listed below.
if 1. Connect the programming device to the specified port of PC (USB/COM port/parallel port)
te
2. Power up the device (Most of the programmers incorporate LED to indicate Device power up.
1s·
Ensure that the power indication LED is ON)
n, 3. Execute the programming utility on the PC and ensure proper connectivity is established between
PC and programmer. In case of error,·tum off device power and try connecting it again
 Introduction to Embedded Systems

DB-9 COM/USB
connector

Device programmer

RS-232/USB cable

4. Unlock the ZIF socket by turning the lock pin

5. Insert the device to be programmed into the open socket as per the insert diagram shown on the
programmer
6. Lock the ZIF socket
7. _Select the device name from the list of supported devices
8. Load the hex file which is to be embedded into the device
9. Program the device by 'Program' option of utility program
10. Wait till the completion of programming operation (Till busy LED of programmer is off)
11. Ensure that programming is successful by checking the status LED on the programmer (Usually
'Green' for success and 'Red' for error condition) or by noticing the feedback from the utility
program
12. Unlock the ZIF socket·and take the device out of programmer
Now the firmware is successfully embedded into the device. Insert the device into the board, power
up the board and test it for the required functionalities. It is to be noted that the most of programmers
support only Dual Inline Package (DIP) chips, since its ZIF socket is designed to accommodate only
DIP chips. Hence programming of cnips with other packages is not possible with the current setup.
Adaptor sockets which convert a non-DIP package to DIP socket can be used for programming such
chips. One side of the Adaptor socket contains a DIP interface and the other side acts as a holder for
holding the chip with a non-DIP package (say VQFP). Option for setting firmware protection will be
available on the programming utility. If you really want the firmware to be protected against unwanted
external access, and if the device is supporting memory protection, enable the memory protection on
the utility before programming the device. The programmer usually erases the existing content of the
chip before programming the chip. Only EEPROM and FLASH memory chips are erasable by the pro-
grammer. Some old embedded systems may be built around UVEPROM chips and such chips should be
erased using a separate 'UV Chip Eraser' before programming.
The major drawback of out-of-circuit programming is the high development time. Whenever the
l
firmware is changed, the chip should be taken out of the development board for re-programming. This
is tedious and prone to. chip damages due to frequent insertion and removal. Better use a socket on the
,,..,.,-board side to .hold-the chip till the firmware modifications are over. The programmer facilitates program-
ming of only one chip at a time and it is-not suitable for batch production. Using a 'Gang Programmer'
 Integration and Testing of Embedded Hardware and Firmware

resolves this issue to certain extent. A gang programmer is similar to an ordinary programmer except
that it contains multiple ZIF sockets (4 to 8) and capable of programming multiple devices at a time.
But it is bit expensive compared to an ordinary programmer. Another big drawback of this programming
technique is that once the product is deployed in the market in a production environment, it is very dif-
ficult to upgrade the finnware.
The out-of-system programming technique is used for finnware integration for low end embedded
products which runs without an operating system. Out-of-circuit progra:mrning is commonly used for
development of low volume products and Proof of Concept (PoC) product Development.

12 .1. 2 In System Programming (ISP)

With ISP, programming is done 'within the system', meaning the finnware is embedded into the target
device withoutremoving it from the target board. It is the most flexible and easy way offinnware· em-
bedding. The only pre-requisite is that the target device must have an ISP support. Apart from the target
board, PC, ISP cable and ISP utility, no other additional hardware is required for ISP. Chips supporting
ISP generates the necessary programming signals internally, using the chip's supply voltage. The target
board can be interfaced to the utility program running on PC tlrrough Serial Port/Parallel Port/USB. The
communication between the target device and ISP utility will be in a serial fonnat. The serial protocols
used for ISP may be 'Joint Test Act~ GrQ~P {JTAG)' or 'Serial Peripheral Interface (SPI)' or any other
proprietary protocol. In order to perfo:rmJSPuperations the target device (in most cases the target device
is a microcontroller/microprocessor) shoula · ~wered up in a special 'ISP.. wgde'. ISP mode allows
the device to communicate with an external host 'ough a serial interface, ·s.uch as a PC or tenninal.
The device receives commands and data from the hos r--erases and reprograms code memory according
to the received command. Once the ISP operations are completed, the device is re-configured so that it
will operate nonnally by applying a reset or a re-power up.
12.1.2.1 In System Programming with SP/ Protocol Devices with SPI In System Programming
support contains a built-in SPI interface and the on-chip EEPROM or FLASH memory is programmed
through this interface. The primary I/0 lines involved in SPI - In System Programming are listed be-
low.
MOSI- Master Out Slave In
MISO - Master In Slave Out
SCK - System Clock
RST - Reset of Target Device
GND Ground of Target Device
PC acts as the master and target device acts as the slave in ISP. The program data is sent to the MOSI
pin of target device and the device acknowledgement is originated from the MISO pin of the device.
SCK pin acts as the clock for data transfer. A utility program can be developed on the PC side to generate
the above signal lines. Since the target device works under a supply voltage less than 5V (TTL/CMOS),
it is better to connect these lines of the target device with the parallel port of the PC. Since Parallel port
operations are also at 5V logic, no need for any other intennediate hardware for signal conversion.
The pins of parallel port to which the ISP pins of device needs to be connected are dependent on the
program, which is used for generating these signals, or you can fix these lines first and then write the
program according to t_he pin inter-connection assignments. Standard SPI-ISP utilities are feely avail-
able on the internet and. there is no need for going for writing own program. What you need to do is just
connect the pins as mentioned by the program requirement. As mentioned earlier, for ISP operations, the
 r
Introduction to Embedded Systems

target device needs to be powered up in a pre-defined sequence. The power up sequence for In System
Programming for Atmel's AT89S series microcontroller family is listed below.
1. Apply supply voltage between VCC and GND pins of target chip.
2. Set RST pin to "HIGH" state.
3. If a crystal is not connected across pins XTALI and XTAL2, apply a 3 MHz to 24 MHz clock to
XTALI pin and wait for at least 10 milliseconds.
4. Enable serial programming by sending the Programming Enable serial instruction to pin MOSI/
Pl.5. The frequency of the shift clock supplied at pin SCK/Pl.7 needs to be less than the CPU
clock at XTALl divided by 40.
5. The Code or Data array is programmed one byte at a time by supplying the address and data to-
gether with the appropriate Write instruction. The selected memory location is first erased before
the new data is written. The write cycle is self-timed and typically takes less than 2.5 ms at 5V.
6. Any memory location can be verified by using the Read instruction, which returns the content at
the selected address at serial output MISO/Pl .6.
7. After successfully programming the device, set RST pin low or tum off the chip power supply and
tum it ON to commence the normal operation.

The key player behind ISP is a factory programmed memory (ROM) called 'Boot ROM. The Boot
ROM normally resides at the top end of code memory space and it varies in the order of a few Kilo Bytes
(For a controller with 64K code memory space and IK Boot ROM, the Boot ROM resides at memory
location FC00H to FFFFH). It contains a set of Low-level Instruction APis and these APis allow the
),rocessor/cphtroller to perform the FLASH memory programming, erasing and Reading operations.
:'.11he contents ofthe,Boot ROM are provided by the chip manufacturer and the same is masked into every
\1evice. The Boot RQM for different family or series devices is different. By default the Reset vector
starts the code memory execution at location 0000H. If the ISP mode is enabled through the special ISP
Power up sequence, the execution will start at the Boot ROM vector location. In System Programming
technique is the best advised programming technique for development work since the effort required to
re-program the device in case of firmware modification is very little. Firmware upgrades for products
supporting ISP is quite simple.

12.1.3 In Application Programming (IAP)

In Application Programming (IAP) is a technique used by the firmware running on the target deyice for
modifying a selected portion of the code memory. It is not a technique for first time embedding of user It

written firmware. It modifies the program code memory under the control of the embedded application. .
Updating calibration data, look-up tables, etc., which are stored in code memory, are typical examples ;,
ofIAP. The Boot ROM resident AP! instructions which perform various functions such as programming,
erasing, and reading the Flash memory during ISP-mode, are made available to the end-user written
firmware for IAP. Thus it is possible for an end-user application to perform operations on the Flash
memory. A common entry point to these API routines is provided for interfacing them to the end-user's
application. Functions are performed by setting up specific registers as required by a specific operation
 Integration and Testing of Embedded Hardware and Firmware

and performing a call to the common entry point. Like any other subroutine call, after completion of
the function, control will return to the end-user's code. The Boot ROM is shadowed with the user code
memory in its address range. This shadowing is controlled by a status bit. When this status bit is set,
accesses to the internal code memory in this address range will be from the Boot ROM When cleared,
accesses will be from the user's code memory. Hence the user should set the status bit prior to calling the
common entry point for IAP operations (The IAP technique described here is for PHILIPS' 89C51RX
series microcontroller. Though the underlying principle in IAP is the same, the shadowing technique
used for switching access between Boot ROM and code memory may be different for other family of.
devices).

12.1.4 Use of Factory Programmed Chip

It is possible to embed the firmware into the target processor/controller memory at the time of chip
fabrication itself. Such chips are known as 'Factory programmed chips'. Once the firmware design is
over and the firmware achieved operational stability, the firmware files can be sent to the chip fabrica-
tor to embed it into the code memory. Factory programmed chips are convenient for mass production
applications and it greatly reduces the product development time. It is not recommended to use factory
programmed chips for development purpose where the firmware undergoes frequent changes. Factory
programmed ICs are bit expensive.

12.1.5 Firmware Loading for Operating System Based Devices

The OS based embedded systems are programmed using the In System Programming (ISP) technique.
OS based embedded systems contain a special piece of code called 'Boot loader' program which takes
control of the OS and application firmware embedding and copying of the OS image to the RAM of the
system for execution. The 'Boot loader' for such embedded systems comes as pre-loaded or it can be
loaded to the memory using the various interface supported like JTAG. The bootloader contains neces-
sary driver initialisation implementation for initialising the supported interfaces like UART, TCP/IP
etc. Bootloader implements menu options for selecting the source for OS image to load (Typical. menu
item examples are L Load from FLASH ROM, Load from Network, Load through UART etc). In case
of the network based loading, the bootloader broadcasts the target's presence over the network and the
host machine on which the OS image resides can identify the target device by capturing this message.
Once a communication link is established between the host and target machine, the OS image can be
directly downloaded to the FLASH memory of the target device. We will discuss about the role of'Boot
loader', 'Boot loader' development and embedding, finnware and OS embedding and booting pl'Ocess
for an OS based embedded system in detail in a dedicated book coming under this series. Please be
patient till then.

Now the firmware is embedded into the target board using one of the programming techniques described
above. 'What Next?' The answer is power up the board. You may be expecting the device functioning
exactly in a way as you designed. But in real scenario it need not be and if the board functions well in
the first attempt itself you are very lucky. Sometimes the first power up may end up in a messy explosion
leaving the smell of burned components behind. It may happen due to various reasons, like Proper care
was not taken in applying the power and power applied in reverse polarity (+ve of supply connected to
 Introduction to Embedded Systems

-ve of the target board and vice versa), components were not placed in the correct polarity order (E.g.
a capacitor on the target board is connected to the board with +ve terminal to -ve of the board and vice

l
versa), etc ... etc ... I would like to share a very interesting incident which happened in my development
career during the power up of a new board. Though the board was well checked and extreme care was
taken in applying the power, when I powered the board after embedding the firmware, 1 heard an explo-
sion followed by the burning of a capacitor on the target board and I really struggled hard to stop the
fire from spreading by a strong puff of air-It is not a joke, Its a true incident. The reason was very
simple, the power applied to the board was ()V and the filter capacitor placed at the regulator I~ input
side was with a rating of 6V (220MFD/6\ Since the capacitor rltage rating was below the input
supply, the dielectric of capacitor got burned. Be· cautious: Before you power up the board make sure
everything is intact. We will discuss about the various tools used for troubleshooting the .target hardware
in a later chapter.

Summary
::·deals witti.the '.d11b'ea4irfgoffinnw~rein to the tatgft{hardware .••
..... .·. d produ~ts/ ifthe processorf.~ontroll&d6ntaini 'i~t~trial . •'•
.· e code riie~oryarea, the code memory is.d6Wnl.oaded
o/c~ntrbiler do~siJn;ttpport built:-in·d§gtnieµidcy:orth'.~ s;iie 6tthl4i'
S\'Zeisµpport~ij by th~ t~gei prqcelisor/gontrofret, the finn;~re kiield ' '
' irs•,;'i;ei{t<' :. 'r .. .. ·.,,. ·•· ; ,,. ' . \·. ; ' ; ' . i" . ... .

✓ 9u~c~f; . liit :Ptogr:' . . < .·• ' Jf~'syXeriLPrdgrarriming {ISP) are "the two aitferent methdds for emb~dquri
'. iiirliwllt¢ m ba11?4 Qpe·r~fmg~~y§tenibased ptoduct
1
"' · .. . . .. . ...... . . . ,' ' ;, x:?~!:;·
✓,~ ·1~1tl}e';~ut~-0f~circuit'.pr6grafuniiig,Ithefde~ice 'is removed from the target board and is;pidgramm~d u ,, '
.'.}15eyice'."Pib~~er\·wµei¢afm,,the ,J~ Syste!ll .Prg~amming technique,· t.he finnwarf JS: ;embeddep ;info, ..
. "COi;ttro}!erinemory/pr:ggr~rp.e~9ry c4ip without removing the chip Jrom the target board .. . ; . . · . . . .· , ..
✓ ,·JiA<l?sP(efo/·aie:the. comrilotilyused serial protocols for transferring the embedded firmware into;thectaiget
device
✓ In Application Programming (IAP) is a technique used by the finnware running on the target device formodifyip,g
a selected portion of the code memory. It is not a technique for first time embedding of user writte,n firmware. It
modifies the program code memory under the control of the embedded application
✓ IAP is normally used for updating calibration data, look~up tables, etc. which are stored in code memory
✓ Factory programmed chip embeds firmware into the chip at the time of chip fabrication
✓ In System Programming (ISP) is used for embedding the OS impge and application program into the non-volatile
storage memory of the embedded product. The bootloader program running in the target device implements the
necessary routine for embedding the OS image into the non-volatile memory and booting the system
j

c~~ Keywords l . l
l
i
II \
•/ I .
.
JTAG An Interface for hardware troubleshooting like boun~~ .sqan testing
· In. Syst~m Programming (ISP) Firmware embedding technique in which the firm'T>'ate isembedded into the
program
.
memory without removing the chip froin1I the target board
Serial Peripheral Interface (SPI) Serial interface for connecting devices
,,_ -:.m:·.
"·· ~-~·

Integration and Testing of Embedded Hardware ~nd Firmware

cfl Review Questions ]

1. Explain the different techniques for embedding the finnware into the target board for a non-OS based embedded
system
2. Explain the major drawbacks of out-ofcircuit programming
3. Explain the firmware embedding process for OS based embedded products
4. What is the difference between In System Programming (ISP) and In Application Programming (IAP)?
 ~ . LEJI.RNING OBJECTIVES
. . '

.Learn aboat 'the' ~IJjelent entin;s. of:ifie embedde~ 'system de .... '. \ ti?rtt ~rivlfqn~'ent· .... ,. },:;It·::; ;1'. . . ·. .' .
'I ,. "' ' """ is', ~ :"' ~ ,..,,,} $);:--i',.,,··~\ .>/,::.'"'" ._,:\"'\t.">.'f-
c,.;\':<'>-·:_\-~·-;~~'-'.;':,;,:·::J(<,..)'!-,({. ..,'', .
dDev?lapment f n\jr?nments (ID£st :9eage~/i.rfnfliare,igt~lqr} ·. . .f1J1lf a,e.bµggtng
'for
)~ . .J:mrtro~}~~iiioftefar~ (www.":Rell.c"ow .emiedderlfi}m;i/ate ;ife}e:gP.in~ni simulation
·s1 /amity oj-1t1i~ro~6QHottersc • ·•· ·:,·\ . ,.; . >·
:< . •. . .,: /: .. > .· ·
. . · ·.• . J;Jrlriirf1bfs %/firm.wart ileveloplh~htJ9r~iffefi~t,!i/Jip.& of PfQfe!fjots!G~ntrai[ers and
>Emp . .. , !tEystems . . . . . . . . .· . . ·. . . . .• . . . . . . . ·..
· ✓. Ld11rn q qytd:hf'ciift?(enttypes offiles (litit File,: Preproc~ssor o·vtpµtftle,, QfJjecf Ffle, 'Map filfH~ file, etc.) gen-
f'tft'#li~~;ftk.ikrass; coi1pi{atio,ngf aJ9urce file ·wri~~nlfl high Wvel iangWg~ like lm~e,jd~ii·t~ha'during'the
ciet~sit~ifm.§lf~u;blilieurc~Jile.<writie,n ih/~s~rnpJyigg§iC" ti,]·. ·•···... . ...••. ·. .·• .... ' . i\<
; •titirn 'tib:~u(!fis.~S,~?ffiMer and decorlipfier/iin<f thiihql.~in: /dijfd.Jirmv.:gt~ ifer~iqPlJ1iht . ; .:, ·. '
✓ ~eqm qbouf~i111yla{or~, In Circuit .Emulators (ICE), ~nd'Debuggers crnd theiuole,jn .emf!edded flrmware debugging
✓. Learn aboutthe.differeni tools and techniques used Jorembe,efil?dnardwdre.debugging
✓ Learn the use of magnifying glass, multimeter, CRO, logic analyser and }unction generator in embedded hardware
debugging
✓ Learn about' the boundary scanning technique for testing the interconnection among the various chips in a complex
hardware board

This chapter is designed to give you an insight into the embedded-system development environment.
The various tools used and the various steps followed in embedded system development are explained
here. It is a summary of the various design and development phases we discussed so far and an intro-
duction to the various design/development/debug tools employed in embedded system development. A
typical embedded system development environment is illustrated in Fig. 13.1.
I
As illustrated in the figure, the development environment consists of a Development Computer (PC)
or Host, which acts as the heart of the development environment, Integrated Development Environ-
ment (IDE) Tool for embedded finnware development and debugging, Electronic Design Automation
(EDA) Tool for Embedded Hardware design, An emulator hardware for debugging the target board,
Signal sources (like Function generator) for simulating the inputs to the target board, Target hardware
 The Embedded System Development Environment

In system programming (ISP) interface (Serial/USB/Parallel/TCP-IP)

Integrated development
environment (IDE) tool

Emulator-Target Board
interface (JTAG/BDM/Pin to
pin socket)
Ein 1
iii:
ator.pc
i.J:

PCB fabrication
files
Multimeter

Hardware debugging tools

( Fig. 13. 1) .The Embedded System Development Environment

debugging tools (Digital CRO, Multimeter, Logic Analyser, etc.) and the target hardware. The Inte-
grated Development Environment (IDE) and Electronic Design Automation (EDA) tools are selected
j
based on the target hardware development requirement and they are supplied as Installable files in CDs
by vendors. These tools need to be installed on the host PC used for development activities. These tools
I•
can be either freeware or licensed copy or evaluation versions. Licensed versions of the tools are fully
featured and fully functional whereas trial versions fall into two categories, tools with limited features,
and full featured copies with limited period of usage.
'.)
l·
n
i,
re In embedded system development context, Integrated Development Environment (IDE) stands for an
integrated environment for developing and debugging the target processor specific embedded firmware.
IDE is a software package which bundles a 'Text Editor (Source 9ode Editor)', 'Cross-compiler (for
 Introduction to Embedded Systems

cross platfonn development and compiler for same platfonn development)', 'Linker' and a 'Debugger'.
Some IDEs may provide interface to target board emulators, Target processor's/controller's Flash mem-
ory programmer, etc. and incorporate other software development utilities like 'Version Control Tool',
'Help File for the Development Language', etc. IDEs can be either command line based or GUI based.
Command line based ID Es may include little or less GUI support. The old version of TURBO C IDE for
developing applications in C/C--t+ for x86 processor on Windows platfonn is an example for a generic
IDE with command line interface. GUI based IDEs provide a Visual Development Environment with
mouse click support for each action. Such IDEs are generally known as Visual IDEs. Visual IDEs are
very helpful in finnware development. A typical example for a Visual IDE is Microsoft® Visual Studio
for developing Visual C--t+ and Visual Basic programs. Other examples are NetBeans and Eclipse.
IDEs used in embedded finnware development are slightly different from the generic IDEs used
for high level language based development for desktop applications. In Embedded Applications, the
IDE is either supplied by the target processor/controller manufacturer or by third party vendors or as
Open Source. MPLAB is an IDE tool supplied by microchip for developing embedded finnware using
their PIC family of microcontrollers. Keil µVision3 (spelt as micro vision three) from Keil software is
an example for a third party IDE, which is used for developing embedded :finnware for 8051 family
microcontrollers. CodeWarrior by Metrowerks is an example of IDE for ARM family of processors.
It should be noted that in embedded finnware development applications each IDE is designed for a
specific family of controllers/processors and it may not be possible to develop :finnware for all family
of controllers/processors using a single IDE (as of now there is no known IDE with support for all fam-
ily of processors/controllers). However there is a rapid move happening towards the open source IDE,
Eclipse for embedded development. Most of the proccessor/control manufacturers and third party IDE
providers are trying to build the IDE around the popular Eclipse open source IDE. This may lead to a
single IDE based on Eclipse for embedded system development in the near future. Since this book is
primarily focusing on 8051 based embedded finnware development, the IDE chosen for demonstration
is Keil µVision3. A demo version of the tool for Microsoft Windows OS based development is avail-
able for free download from the Keil Software website. Please instal the same on your ·machine before
proceeding to the next sections.

13.1.1 The Keil µVision3 IDE for 8051

Keil µVision3 is a licensed IDE tool from Keil Software (www.keil.com), an ARM company, for 8051
family rnicrocontroller based embedded finnware development. To start with the IDE (after installing
the demo tool) execute the program Uv3.exe (or the short cut 'Keilµ Vision3' from desktop or 'All Pro-
grams' tab from 'Start Menu' - For Host machine with Microsoft® Windows Operating System). The
IDE view is shown in Fig. 13.2..
The IDE looks very similar to the Microsoft® Visual Studio IDE and it contains various menu op-
tions, a project window showing files, Register view, Books and Functions Tab and an output window.
To start a new project, go to the 'Project'.,tab on the menu, select 'New Project' option. Give a name
to your workspace in the 'File Name' section of the 'Create New Project' Pop-up dialog Box (Let it be
'sample'). Choose the directory to save the project from the pop-up dialog. The default extension of a
project workspace file is .uv2. On clickingthe 'Save' button of the 'Create New Project' pop.,.up dialog,
a device selection dialog as shown in Fig. 13.3 appears on the screen.
This Dialog Box lists out all the vendors (manufacturers) for 8051 familymicrocontroller, supported
by IDE. Choose the manufacturer of the chip for your design (Let it be 'Atmel' for our design). Atmel
itself manufactures a variety of 8051 flavours. Choose the exact part nuij!ber of the device used as the
 The Embedded System Development Environment

Project Window

Output Window

''<.:_;,,-,.,,' . ·_··,,:,;,.\,»'

1•µVi!?(QJ13'.Integrated.Development
/•, ·-:,. '="'·"·....... '
Environment
•
(IDE)

[)esgiption:
IE- Acer Labs ,,; •
d:i ♦ M.el
l"fl· ♦ Aero!lex UTMC
l1:].1'ltium

I
$· ♦ Arlalog Devices
£/J· ♦ .AochorCh1ps
tB ♦-
$ ♦ Alme! Wireless &uC
ltl ♦ uist, Inc
1 ft ♦ Chipcon
1 $ ♦ CML M1crocircurts
[fl ... Cybernetic Micro Systems
....
[fl· ♦____Cybra
_
Tech

0K Cancel

QFig-~ 13.3)
1 Target CPUV,....~dor selection for Keil µVision3 IDE
 .
r
f.

l
Introduction to Embedded Systems f

target processor for the design, by expanding the vendor node. It will list out all supported CPUs by
the selected vendor under the vendor node. On selecting the target processor's exact part number, the
vendor name, device name and tool set supported for the device is displayed on the appropriate fields of '
the dialog box along with a small description of the target processor under the Description column on ~
the right side of the pop-up dialog as shown below. Press 'OK' to proceed after selecting the target CPU
(Let it be 'AT89C51' for our design).

: Q AT83/89C5132 8051-based Fullly Static 24MHz:GMOSco

Q AT8.3EB5114 2T mera/Countera; 6 lntemipts/2 Pri() .
CJAT87F51
. 1hree·levef Program Memory lock. 4K Bytes Rash
128 Bytes Ori-chip RAM
Q AT87F51RC
Q AT&7F52
Q AT87F55WD
Q AT89C1051
Q AT89C1051U
L Q AT89C2051
Q AT89C4051
·QliiP!iJ
• Q AT89C5115
L Q AT89C5131

OK j Cancel

( Fig. 13.4) Target CPU selection for Keil µVision3 IDE

Once the target processor is selected. the IDE autornat1cally adds the required startup code for the
firmware and it prompts you whether the standard startup code needs to be added to the project (Fig.
13.5). Press 'Yes' to proceed. The startup code contains the reqmred default initialisation like stack
pointer setting and initialisation. memory clearjng. etc. On cross-compiling, the code generated for
the startup file is placed on top of the code generated for the function mainO. Hence the reset vector

Copy Standard 8051 Startup Code to Project Folder and Add File 1:o

I
(Fig. 13:5) Startup file addition to the project
 The Embedded System Development Environment

(0000H) always starts with the execution of startup code before the main code. For more details on
the contents and code of startup file please go through the µVision help files which is listed under the
.'Books' section of the project workspace window.
A 'Target' group with the name 'Target]' is automatically generated under the 'Files' section of the
project Window. 'Targetl' contains a 'Source Group' with the name 'Source Group]' and the startup
file (STARTUP.AS I) is kept under this group (Fig. 13.6). All these groups are generated automatically.
If you want you can rename these groups by clicking the respective group names.

~
r,,;
!~
<.Q

IL , ,►1 .,.:,.,J;.<o~oo A.aoo •a"'-'

]unknown Target ·· i .· · ·· ·i ,'.%

( Fig. 13.6) Startup file added to the project

You can see that similar to the Visual Studio IDE's 'Project Window' for VC++ development, Keil
IDE 's 'Project Window' also contains multiple tabs. They are the 'Files' tab, which gives the file details
for the current project, 'Regs' tab, giving the Register details while debugging the source code, 'Books'
tab showing all the available help and documentation files supplied by the IDE, 'Functions' tab lists out
the functions present in a 'C' source file and finally a 'Templates' tab which generate automatic code
framework (function body) for if, if else, switch case etc and code documentation template (Header).
These steps create a project workspace. To start with the finnware development we need to create a
source file and then add that source file to the 'Source Group' of the 'Target'. Click on the 'File' tab on
the menu tool of the IDE and select the option 'New'. A blank text editor will be visible on the IDE to
the right of the 'Project Window'. Start writing the code on the text editor as per your design (Refer to
 Introduction to Embedded Systems
rI
the Keil help file for using Keil supported specific Embedded C instructions for 8051 family). You can
write the program in ANSI C and 8051 specific codes (like Port Access, bit manipulation instruction
I1
etc) using Keil specific Embedded C codes. For using the Keil specific Embedded code, you need to add
the specific header file to the text editor using the #include compiler directive. For example, #include j
<reg51.h> is the header file including all the target processor specific declarations for 8051 family pro-
cessors for Keil C51 Compiler. Standard 'C' programs (Desktop applications) calls the library routines
for accessing the UO and they are defined in the stdio.h file, whereas these library files cannot be used as
such for embedded application development since the UO medium is not a graphic console as in the C
language based development on DOS Operating system and they are re-defined for the target processor
I/Os for the cross compilers by the cross compiler developer. If you open the stdio.h file by ANSI C and
Keil for its IDE, you can find that the implementation of UO related functions (e.g. printfO) are entirely
different. · · .
The difference in the implementation is explained with typical stdio.h function-printfO (e.g.
printf("Hello World\n '')). With ANSI C & DOS the function outputs the string Hello World to the DOS
console whereas with the C5 l cross-compiler, the same function outputs the string Hello World to the
serial port of the device with the default settings. Coming back to the firmware development, let's follow
the universal unwritten law of first 'C' program- The "Hello World' program. Write a simple 'C' code to
print the string Hello world.

i 'j
;j

]
;j

l
(~g;J;3.7) Writing the fll'St Embedded C code
l
r The Embedded System Development Environment

The code is written in the text editor which appears within the IDE on selecting the 'New' tab from
the 'File' Menu. Write the code in C language syntax (Fig. 13.7). Add the necessary header files. You
can make use of the standard template files available under the 'Templates' tab of the 'Project Window'
for adding functions, loops, conditional instructions, etc. for writing the code. Once you are done with
the code, save it with extension .c in a desired folder (Preferably in the current project directory). Let the
name of the file be 'sample.c'. At the moment you save the program with extension .c, all the keywords
(like #include, int, void, etc.) appear in a different colour and the title bar of the IDE displays the name
of the current .c file along with its path. By now we have created a 'c' source file. Next step is adding the
created source file to the project. For this, right click on the 'Source Group' from the 'Project Window'·
and select the option 'Add Files to Group 'Source Group". Choose the file 'sample.c' from the file se-
lection Dialog Box and press 'Add' button and exit the file selection dialog by pressing 'Close' button.
Now the file is added to the target project (Fig. 13.8). You can see the file in the 'Project Window' under
'Files' tab beneath the 'Source Group'.

·, s
:"'" ..
r!J . . ::

New file Added to Project

1
l (f'tg, 13;8) Adding Files to the Project

If you are following the modular programming technique, you may have different source files for
performing an intended operation. Add all those files to the project as described above. It should be
noted that function mainQ is the only entry point and only one '.c' file among the files added to the
project is ailowed to contain the function mainQ. If more than one file contains a function with the name
mainQ, compilation will end up in error. The next step is configuring the target. To configure the target,
 Introduction to Embedded Systems

go to 'Project' tab on the Menu and select 'Options for Target'. The configuration window as shown in
Fig. 13 .9 is displayed.

( Fig. 13.9) Target Configuration

The target configuration window is a tabbed dialog box. The device is already configmed at the time
of creating a new project by selecting the target device (e.g. Atmel AT89C5 l ). If you want to check it,
select the 'Device' tab and verify the same. Select 'Target' tab and configure the following. Give the
clock frequency for which the system is designed. e.g. 6MHz, 11.0592MHz, 12MHz, 24MHz, etc. This
has nothing to do with the finnware creation but it is very essential while debugging the firmware to note
the execution time since execution time is dependent on the clock frequency. If the system is designed
to make use of the processor resident code memory, select the option Use On-chip ROM (For AT89C5 l
On-chip ROM is 4K only; Ox0O00 to Ox0FFF). If external code memory is used, enter the start address
and size of the code memory at the Off-chip Code memory column (e.g. Eprom Start: 0x000O and Size
OxOFFF). The working memory (data memory or RAM) can also be either internal or external to the
processor. If it is external, enter the memory map starting address of the external memory along with
the size of external memory in the 'Off-chip Xdata memory section Ram Start: 0x8000 and Size Ox
1000). Select the memory model for the target. Memory model refers to the data memory. Keil supports
three types of data memory model; internal data memory (Small), external data memory in paged mode
(Compact) and external data memory in non-paged mode (Large). Now select the Code memory size.
 The Embedded System Development Environment

Code memory model is also classified into three; namely, Small (code less than 2K bytes), Compact (2K
bytes functions and 64K bytes code memory) and Large (Plain 64K bytes ~emory). Choose the type
depending on your target application and target hardware design. If your design is for an RIOS based
system, select the supported RTOS by the IDE. Keil supports two 8 bit RTOS namely, RTX51 Tiny and
RTX5 l Full. Choose none for a non RTOS based design.
Move to the next Tab, 'Output'. The output tab holds the settings for output file generation from the
source code (Fig. 13.10). The source file can either be converted into an executable machine code or a
library file.

I
I ( Fig. 13.10 Output File creation settings

Yot1 can select one of the output settings (viz. executable binary file (hex) or library file (lib)). For
executable file, tick the 'Create Hex File' option and select the target processor specific hex file fonnat.
Depending on the target processor architecture the hex file fonnat may vary, e.g. Intel Hex file and
Motorola hex file. For 8051, only one choice is available and it is Intel hex File HEX-80. The list files
section coming under the tab 'Listing' tells what all listing files should be created during cross-compila-
tion process (Fig. 13.11).
'C51' tab settings are used for cross compiler directives and settings like/Pre-processor symbols,
code optimisation settings, type of optimisation (viz. code optimised for execution speed and code
optimised for size), include file's path settings, etc. The 'A5 I' tab settings are used for assembler direc-
 Introduction to Embedded Systems

(Fig. 13.11) ListFile generation settings

tives and settings like conditional assembly control symbols, include file's path settings etc. Another
important option is 'Debug'. The 'Debug' tab is used for configuring the firmware debugging. 'Debug'
supports both simulation type firmware debugging and debugging the application while it is limning on
l
i,
the target hardware (Fig. 13 .12).
You can either select the Simulator based firmware debugging or a target firmware level debugging
from the 'Debug' option. If the Simulator is selected, the finnware need not be downloaded into the
target machine. The IDE provides an application firm.ware debugging environment by simulating the
target hardware in a software environment. It is most suitable for offline analysis and rapid code devel-
opments. If target level debugging is selected, the binary file created by the cross-compilation process
needs to be downloaded into the target hardware and the debugging is done by single stepping the
firmware. A physical link should be established between the target hardware and the PC on which the
IDE is running for target level debugging. Target level hardware debugging is achieved using the Keil
supported monitor programs or through an emulator interface. Se,lect the same from the Drop-down list.
Normally the link between target hardware and IDE is established through a Serial interface. Use the
settings tab to configure the Serial interface. Select the 'Comm Port' to which the target device is con- ~.
nected and the baudrate for communication (Fig. 13.13). ,
If the Debug mode is configured to use the Target level debugging using any one of the monitor
program or the emulator interface supported by the Keil IDE, the created binary file is downloaded into l 1 (

l
 The Embedded System Development Environment

15051 In-System
N390 Dallas Conti
EPM Emulator
-uPSD UUNKOriv
eon XCSOO UUN
onltorO!iver

,,,

~ OialogOLL: Parameter:
:Lc1ops, .oLL- 1-ps1
, ~: ,>,._-.,

'\ •oiz · ·I ·'.i:O!ncil!

J;7 Load ,\>pucation at

lnftialization Rle: Baudrate: j9600

- Cache Uot1orn:----···--··-·-------------·----·--1
1
Debug Sessi I P' Cache DATA (SFR) P' CacheXDATA
f7 Breakpoints I P Cache !DATA P- Cache CODE
P Watchpoints & [----------------~~-➔·-~-- \

r· Stop Program Execution with ·

l r Serial Interrupt

CPU DLL.
jS8051 DLL

Dialog DLL:
IDP51DLL
OK Cancel I
OK Cancel Defaults Help I
'ig: '13. 13) Target hardware debug serial link configuration
 hct:·;
-.. 3!'
·1ro

Introduction to Embedded Systems t

the target board using the configured serial connection and the firmware execution occurs in real time.
The firmware is single stepped (Executing instruction-by-instruction) within the target processor and
the monitor program running on the target device reflects the various register and memory contents in
the IDE using the serial interface.
The' Utilities' tab is used for configuring the flash memory programming of the target processor/con-
trollers from the Keil IDE (Fig. 13.14). You can use either Keil IDE supported programming drivers or
a third party tool for programming the target system's FLASH memory. For making use of Keil IDE
provided flash memory programming drivers, select the option 'Use Target Driver for Flash Program-
ming' and choose a driver from the drop-down list. To use third party programming tools, select the
option 'Use External Tool for Flash Programming' and specify the third party tool to be used by giving
the path in the '_Command' column and specify the arguments (if any) in the 'Arguments' tab to invoke
the third party application.

Defaults . I Help ··--- j

( Fig. 13.14) Target Flash Memory Programming configuration

With this we are done with the writing of our first simple Embedded C program and configuring the
target controller for running it. The next step is the conversion of the fim1ware written in Embedded C
to machine language corresponding to the target processor/controller. This step is called cross-compila-
tion. Go to 'Project' tab in the menu and select 'Rebuild all target files'. This cross-compiles all the files
within the target group (for modular programs there may be multiple source files) and link the object
codes created by each file to generate the final binary. The output of cross-compilation for the "Hello
World'' application is given in Fig. 13.15.

I
 The Embedded System Development Environment

Build target Target l' ·

1

compi 1 i ng sample. c .......

1inking. . .
1
'f
------11
Data memory= 30 Bytes+ 1 Bit I
Program Size: data=30.1 xdata=O code=1078
creating hex file from 11 sample 11 • • •
11
sample 11 - 0 Error(s), 0 Warning(s).

You can see the cross-compilation step & linking in the o/p window along with cross-compilation er-
ror history. Now perform a 'Build Target' oper;ition. This links all the object files created (in a multi-file
system where each source files are cross-compiled separately) (Fig. 13.16).

Build target 'Target l'

compiling sample.c ...
1 inking ...
Program Size: data=30.1 xdata=O code=1078
creating hex file from sample 11 11
•••
11
sample 11 - 0 Error (s), 0 v\1arning (s) .

In a multi source file project (source group containing multiple .c files) each file can be separately
cross-compiled by selecting the 'Translate current file' option. This is known as Selective Compila-
tion. Remember this gener"tes the object file for the current file only and it needs to be combined with
object files generated for other files, by using 'Build Target' option for creating the final executable
(Fig. 13.17). Selective compilation is very helpful in a multifile project where a modified file only needs
to be re-compiled and it saves the time in re-compiling all the files present in the target group.
1
~ compi 1 ing sample. c ...
sample.c - 0 Error(s), 0 Warning(s).
 Introduction to Embedded Systems

See the difference between the three; selective compilation cross-compiles a selected source file and
creates a re-locatable object file corresponding to it, whereas 'Build Target' performs the linking of
different re-locatable object files and generates an absolute object file and finally creates a binary file.
'Rebuild all target file' creates re.,locatable object files by cross-conwiling all source files and links all
object files to generate the absolute object file and finally generates the binary file. If there is any error
in the compilation, it is displayed on the output window along with the line number of code where the
error is occurred. So it is easy to trace the code to find out the error part in the code. The error is listed
out in the output window along with line number and error description. On clicking the error description
at the output window, the line of code generated th~ error is highlighted with a bold arrow. One example
of error code is given below. In the "Hello Wotldf'--example, the include file is commented and the code
while compiling will generate the error indicatingprineffunction is not defined. Have a look at the same
(Fig. 13.18).

(Source of Error)
Source Group 1
It] STARTUP.A51
It] sample.c rintf ("Hello World\n"); Error generating source
1 code line

i Build target 'Ta

', compiling sample.c ...

Error Descriotion

(Fig.13.18) CompilationErrorExample

13.1.1.1 Debugging with Keil µVision3 IDE Debugging firmware is the process of monitoring
the program flow, various registers and memory contents while the firmware is executed. You can de-
bug the firmware in two methods. The first method is by using breakpoints and· simulator (a software
tool which simulates the functionalities of the target processor). The second method is hardware level
debugging.
 The Embedded System Development Environment

For simulator-based debugging, select the option 'Use Simulator' from the 'Debug' tab of the
'Options for Target' as illustrated in a previous section on debug. Insert a 'Breakpoint' in the code line
of the source.program where debugging needs to be started. Breakpoints can be inserted by right click-
ing on the desired source code line and by selecting the 'Insert/Remove Breakpoint' option. It can also
be inserted by using the 'Debug' tab present in the menu of the IDE (Not the debug tab of Options for
Target Pop-up dialog). It toggles the breakpoint (if the breakpoint is already inserted, it is removed and
if not a breakpoint is added). The breakpoint breaks the firmware execution at the selected point and
further execution requires user interaction. After a break, the code can be executed by single stepping or
by a complete run again. For the above 'Hello World' example, we are going to debug the firmware at
the source code line printf and a breakpoint is inserted as shown in Fig. 13 .19.

El·--®i Source Group 1 main(voidl

f...., (l;} STAR1UP ..A51
HJ-· (l;} sample.c rintf("Hello World\nn);
}

compi 1 ing sample. c ...

1 inking ...
Program Size: da.ta.=30 .1 xdata=O code=1078
creatin'g hex file from "sample"... )
"samp ~ e" - 0 ~E_r_r_o_r_(s_).--,_□,........W_a_r_,n.,,..in_s_(_.s_)_·---------, .......,._ __.I ►..· ..,. .
I~ I .

(Fig; 13:19) Breakpoint insertion and debugging

The 'breakpoint' is distinguishable with a special visible mark. All debug related actions are grouped
within the 'Debug' tab of the IDE menu. Each debug instruction has a hot key (e.g. Ctrl+F5 for start and
stop of debugging) associated with it. Identify the hotkey and use it or use mouse to activate the debug
related action each time from the debug menu. To start debugging, select the option 'Start/Stop Debug
Session (Ctrl+F5)' from the 'Debug' menu. If you set the option 'Go till main0' on the 'Debug' tab of
 Introduction to Embedded Systems

'Options for Target', the application runs till the code memory where the main() function starts. If this
option is not selected, the execution breaks at the Reset vector (OxOOOO) itself Both of these options
are shown below. Note that while debugging, the project window tab automatically selects the 'Regs'
tab and shows the various register contents in this window when the program is at the break stage. You
can switch the project window in between the 'Files' section and 'Regs' section to find out the changes.1._l.~
happening to various registers on executing each line of code (Fig.13.20). .

3: int main(void)
:OxOC2A 7BFF MOV R3 .. #0xFF
: OxOC2C 7AOC MOV . R2 .. #0xOC
(kOO :OxOC2E 7911 MOV RL#Oxll
r1 {IKOO :OxOC30 020862 LJMP P.RINTF(C:086
r2 {kOO :OxOC33 00 NOP.
Ox:00 :OxOC34 00 NOP
:0¥0C35 OD NOP

Register view Finnware execution breaks at function main (void)

.Jtlx:ct .....
:Ox0003
:Ox0004
:Ox0005
:Ox0006
a :Ox0007
·r3 : Ox0008
~ :Ox0009
r5

Finnware execution breaks at Reset vector (0x0000)

( Fig. 13.:W) Firmware execution Break optiops

If you observe these two figures you can see that code memory .execution starts at location OxOOOO
and the firmware corresponding to the function main is located at Ox0C2A and it is not the first execut-
able code. Before executing main Osome other code placed at location OxOCIE (jump from the reset
vector to location OxOC 1E) is executed. The code at this memory location is the code memory generated
for the startup file. Startup file code is always executed before entering the function main. It should be
noted that the code memory location mentioned here for functiqn main is not always fixed. It varies
depending on the changes made to the startup file. From this breakpoint you can go to the breakpoint
you set in the code memory either by single stepping ('Step' command (Fll)) or by a run to the next
breakpoint ('Go' command (F5)).
 The Embedded System Development Environment

3: int main(void)
C:OxOC2A 7BFF MOV R3,#0xFF
C:OxOC2C 7AOC MOV R2,#0xOC
'c: OxOC2E 7911 MOV RL#Ox 11
rintf("Hello World\n"); C:OxOC30 020862 LJMP PRINTF(C:0862)
C: OxOC33 00 NOP
C:Ox0C34 00 NOP
C: OxOC35 00 NOP

By default, the text editor window in debug mode contains two tabs, namely Source code view tab
and Disassembly tab. The Source code and corresponding Disassembly view is shown in Fig. 13.21.
While debugging the firmware you can switch the view between Assembly code and original source
code lines by selecting the corresponding tab. This switches the view between the original source code
and the corresponding Assembly code for it. The Disassembly view disappears temporarily if you click
the 'Disassembly Window' option under the 'View' tab of the IDE menu. To enable Disassembly View
click again on the 'Disassembly Window' option under the 'View' tab of the IDE menu (Fig. 13 .22).

IPr9ject .V~q~e . ',,. ,•· ,;']:~!i• [

El -~ Target l
El @;ii Source Group 1
! [!j STAA1UP,A51
[fl Gr) isa111J)ie:c rintf ("Hello Warld\n");
}

Source view tab

( Fig.13.22) Workbook Mode for Source-Disassembly code View

During debugging the content of various CPU and general purpose registers are displayed under the
'Regs' tab of the project Window. Apart from this you can inspect the data memory and code memory
by invoking the 'Memory Window' under the' View' tab of the IDE menu (Fig. 13.23).
For viewing the Data memory, use the Prefix 'D:' before the address and type it at the Address edit
box and press enter (For example, for viewing the data memory starting from 0x00, type D:0x00 at the
Address box and press enter). You can edit the content of the desired data memory by right clicking
on the current contents pointed by the address or just by a double click on the current content. Code
memory can also be inspected and modified in a similar way to the Data memory. The only difference
is instead of D: use 'C:' (D stands for Data and C stands for Code) (Fig. 13.24).
Similar to other Desktop application development IDEs, this also provides option for viewing local
variables and call stack details. Invoke 'Watch & Call Stack Window' from the 'View' tab of the IDE
menu (Fig. 13.25).
 Introduction to Embedded Systems

.,J
4
Type start address here il
:I

I
i

( Fig. 13.24) Memory modification while debugging

( Fig.13.26) W<1~9~ and Call Stack Window for Debugging

The local variables can be viewed in the 'Locals' section of' Watch and call Stack Window' whereas
users can add other variables to the' Watch' window to get their yalues. 'Call Stack' gives the 'Callee-
Caller' details for subroutine calls. Invoking 'Symbol Window' udder the 'View' tab of IDE menu while
• I
debugging, displays the list of 'Publics', 'Locals' and 'Lines' use,d,by the applicat1011;, in the disassembly
 The Embedded System Development Environment

I window (Assembly code). Selecting 'Publics' shows the different variables and functions present in
the Assembly code along with their 'Address', 'Name' and 'Type'. Address can either be Data memory
address or Code memory address. 'Type' indicates whether it is a variable or a function. Tne different
variables supported are 'unsigned char (uchar)', 'signed char (char)', bit, unsigned integer (uint), signed
int (int), etc. Figure 13.26 shows the Symbols Window displaying the various symbols used in Assem-
bly for our sample application. ·

D:0:-:08 ?_PRINTF517?BYTE
D:0:-:08 ?_PRINT F?BYTE
D:OxOB ?_SPRINTF51 ??BYTE uchar
D:Ox08 ?_SPRINTF?BYTE uchar
D:0:-:EO A uchar
0:-:D0.6 AC bit
D:OxEO ACC uchar
D:OxFO B uchar
C:0:-:03C7 C?Cet,.SE function
C:0:-:0378 C?CLDOPTR function
C:0:-:035F C?CLDPTR function
C:0:-:03A5 C?CSTPTR function

( Fig. 13;26) Symbols Window showing the various symbols used in .Assembly

Activating the 'Code Coverage' option under the 'View' tab of the IDE menu when the execution
is at halted stage, gives the details of instructions in each function/module and how many of them are
executed till execution break. Figure 13.27 illustrates the same.
13.1.1.2 Simulating Peripherals and Interrupts with Keil µVision3 IDE Embedded systems
are designed.to interact with real world and the actions performed by them may depend on the inputs
from various sensors connected to the processor/controller of the embedded system. By a mere software
simulation of the firmware, we can only inspect the memory, register contents, etc. of the processor and
cannot infer anything on the real-time performance of the system since the inputs provided by the sen-
sors are real-time and dynamic. To a certain extent, we can simulate these inputs using the simulator
support provided by the IDE. Keil provides extensive support for simulating various peripherals like;
ports, memory mapped I/O, etc. and Interrupts (External, Timer and Serial interrupts). The main limita-
tipn of simulation is that we can simulate it with only known values (in a real application the simulated
value may not be the real input) and also it is difficult to predict the real-time behaviour of the system
 Introduction to Embedded Systems

1omt of 6inmictions
0% of S instructions
0% of 4instructions

based on these simulations. In our "Hello World' application, if we debug the application by placing a
breakpoint at the 'printf function, in the source code window you can observe that the 'printf function
is not getting completed on single stepping and it gives you the feeling that the firmware is hang up
somewhere. If you are single stepping (using Fll) the firmware from the beginning, in the disassembly
window you can see that for the code corresponding to print/, the application is looping inside another
function called 'putchar', which checks a bit TI (Transmit Interrupt) and loops till it is asserted high
(Fig. 13.28). As we mentioned earlier, the print/ function is outputting the data to the Serial port. As
long as the Transmit Interrupt is not asserted, the firmware control is looped there and it generates an
application hang-up behaviour. If you are not able to view the point where the firmware loops in the
Disassembly window, invoke 'Stop Running' from 'Debug' tab ofIDE menu. The firmware execution
will be stopped and in the disassembly window you can see the exact point where the application was
looping.
IPro~\'lor~e . PIJTCHAR:
je~'ra[l)eti :OxOBEA EF MOV A,R7
El··~ Source Group 1 :OxOBEB B40A07 CJNE A,#OxOILC: OBFS
!· BJ STARTUP.ASl :OxOBEE 7400 MOV A,#OxOD
±,· r+'1
d., J
UJ sampe.c :OxOBFO 120BF5 LCALL C:OBFS
:OxOBF3 740l>. MOV A,#OxOA
C:OxOBFS 309811 JNB RI(Ox98.0),C:OC09
: OxOBFB A899 MOV RO,SBUF(Ox99)
:OxOBFA B8130C CJNE RO,#Oxl3,C: OC09
:OxOBFD C298 CLR RI(Ox98.0)
:OxOBFF 3098FD JNB RI(Ox98.0),C:OBFF .•,·.·
:OxOC02 A899 MOV RO ,SBUF ( Ox99) '
:OxOC04 C298 CLR RI(Ox98.0) l
:OxOCOEi B811F6 CJNE RO,#Oxll,C:OBFF .
(fifoqo§ .3JJ9/JFD JNB TI(Px98.l) ;C:0009y~'·
:.□ xOCOC C299 CLR TI ( Ox98. 1l ,!IJI
~Jft,:

(Fig.13.28) ·Fi,i-mware·Execu.tionwaiting for Transrrtiiintei-rupt (TI)

 The Embedded System Development Environment

We can simulate the Transmit Interrupt 'TI' using the simulator support provided by Keil. If you have
already stopped the execution, continue the code execution by invoking 'Go' option from 'Debug' tab
or by pressing 'F5' key. Now select 'Interrupt' option from the 'Peripherals' tab of the IDE menu. The
interrupt simulation window will pop-up. Select the 'Serial Xmit' interrupt and enable the Global Inter-
rupt Enable (EA) as well as Transmit Interrupt (Tl) (Fig. 13 .29).

Timer 0
P3.3/lnt1
Timer 1
Serial Rev.

You can simulate any other interrupt listed in the interrupt system in a similar fashion. On enabling
TI, finnware execution comes out of the infinite loop and dumps the string "Hello World" to the serial
port. The output of 'Hello World' application is shown in Fig. 13.30. You ~an capture whatever data go-
ing through the serial port while simulation. For this invoke 'Serial Window #1' from the 'View' tab of
the IDE menu.

El~ Target 1

I El-@3 Source Group 1

' GE)
Bl GE)
STAR1llP.AS1
sample.c

[·Fig.'13;30) 'OM-tp'u,_t•of 'Hello World' Application at Serial Port

 Introduction to Embedded Systems

To simulate the Ports and their status, select 'J/O-Ports' from the 'Peripherals' tab of IDE menu
(Fig. B.31).

The first value (E.g. PO: OxFF) simulates the contents of Port OSpecial Function Register. In order to
make the port pins as input pins the port pin's corresponding SFR bit should be .set as 1. With the SFR
bit set to 1, the state of the corresponding port pin can be changed to either logie 1 or logic 0. To output
logic Oto a port pin, clear the corresponding SFR bit and for outputting logic 1, set the corresponding
port bit in the SFR bit. In the above example, if Port Ois viewed as an .output port, the port will be out-
putting all ls. If it is treated as an input port, the value inputted will be OxOF (which-is-the state of the
port pins). Serial Port and Timers can also be simulated by selecting the respective commands from the
'Peripherals' tab of the IDE menu. It is left for the readers for experimenting. The 'Reset CPU' option
available under the 'Peripherals' tab is used for resetting the firmware execution. Resetting the CPU
while debugging brings the program execution to the reset vector (OxOOOO).

E:!;,!OxODOb
"·'. '
020ClE ;;EJMP C:0GlE
. rget 1 :Ox0003 00 NOP
El·-~ Source Group 1 :Ox0004 00 NOP
!· [II STAR1UP.A51 . : Ox0005 00 NOP
[fl [tJ sample:c :Ox0006 00 NOP
:Ox0007 00 NOP
:OxOOOB OD NOP
:Ox0009 00 NOP
:OxOOOA 00 NOP
:OxOOOB .oo NOP
:OxOOOC 00 NOP

(Fig.13.-32) Resetting CPU while Debug in progress

 The Embedded System Development Environment

Generating precise delays in software for super loop based embedded applications are often quite
difficult and there are no standard functions available for generating precise delays. If the 'C' program
is running on DOS platform, there is a standard function 'delayQ' avail~ble which generates delay with
multiples of millisecond. There are no such standard functions available for generating delays in non-op-
erating system based embedded programming. The only way of generating delays is writing a loop and
set its parameters according to the clock frequency used. Often we need to do a trial and error method to
finetune the parameters depending on the crystal used. ~he 'Performance analyser' support by the Keil
IDE helps in calculating the time consumed by a function. To activate this, select 'Pe,formance Anafy::
ser ... ' from the 'Debug' tab of the IDE menu while debugging is on, before entering the function whose
exectltion time needs to be calculated. A Performance analyser set up for selected function is shown in
Fig: J3.33.

dela_i,,_ms (C:Ox0414]
main {C:Ox0432)
PRINTF (C:Ox0065)
PUT CHAR [C:Ox03ED)

( Fig. 13.33) Performance Analyser setup for selected function

The various functions available on the current rm1dule is listed-on the right side of the 'Setup Per-
formance analyser' window under the 'Functzon symbols:' section. Double clicking on the function of
interest displays the same on the 'Define Pe,formance Analyser Range:' Click the 'Define' button to add
it to the analyser. Invoke the 'Performance analyser window' from the 'View' tab of the IDE menu. A
new tab with name 'Performance ... ' will be added to the text editor window. Now execute the function
whose execution time is to be analysed by single step (Fll) or by giving a step Over (FJO) command.
Select the tab 'Performance ... ' and click on the function name for which the analysis is performed.
The time taken for executing the function is displayed at the 'total time' display window. This gives a
rough estimate on the execution time of the function (Fig. 13.34). Note that in addition to this time, t~_
time take.n for calling this function also needs to be taken into account. Moreover, all these calculations
are based on the target clock frequency set on the target options. We will discuss the same for a new
function for generating milliseconds delay added to our program 'Hello World' application. The main
 Introduction to Embedded Systems

Total execution time= 0.9983 ms

function calls the delay routine delay_msO before executing the prinif function. To verify that this func-
tion is taking 1 millisecond time to finish execution with parameter 1, add the function to the perfor-
mance-analyser as mentioned above. Invoke the performance analyser and execute the function. Switch
view to 'Performance ... ' tab and observe the execution time. The complete source code for including
delay is given below.
'"\.f/:i.nc:l tide '<stdio . h>
·;/kiirs1:l;•~·~;~rqt9~tre tor miliisec~t~f\,
void· delay_{2Il1$ ( intJ ;

· int main (void)

f
//Calling 1 millisecond delay
delay_ms .(1);
printf(•Hello World\nn);
}
//###################l##l################################f###########
//Function for generating milliseconds delay
//Assumes clock frequency==24MHz

void delay_ms (int n)

'L

; j<n; j++)

k<247; k++);
/

It should be noted that generating highly precise delay is very difficult and there may be a tolerance
of fraction of millisecond§ in the delay. Also the delay is purely dependent on the system clock
 The Embedded System Development Environment

frequency. In a real world scenario, the stability of the clock is expressed in terms of+/- some parts per
million (ppm) of the fundamental frequency. Any change in the target clock frequency needs the re-tun-
ing of the code to bring it back to the desired tolerance level. Precise time defay,can be generated using
the hardware timer unit of the microcontroller. ·
13.1.1.3 Target Level Firmware Debugging with Keil µVision3 IDE Simulation based de-
bugging technique lacks real-time behaviour and various input conditions needs to be simulated. using
the IDE support for debugging the firmware. Target level hardware debugging involve1 del;mgging the
fimiware which is embedded in the target board. This technique is also known as In Circuit-Debug-
ging/ Emulation (ICD/E). For perfomiing tl!rget level debugging with Keil, the target board should be .
connected to the development machine through a serial interface. The IDE debug settings should be
modified to activate target level debugging. Select the 'Debug' option from 'Options for Targe( and
change 'Use Simulator' to 'Use:' selected debug support from a list of available target debug supports
(Fig. 13.35).

Dialog DLL:
IDP5lDLL

( Fig. 13.36) Configuring IDE Debug settings for target level debugging

Select the target supported debug option from the drivers available on the drop-down list and config-
ure the serial link properties using the 'Settings' tab. Keil supports two types of target level debugging,
namely ',Monitor program based debugging' and 'Emulator based debugging'. For Monitor program
based debugging, the target processor should have Keil IDE supported monitor program installed and
the target hardware should be configured to run the monitor program. Debug instructions from the IDE
communicates with the monitor program running on the target processor and it returns the debug infor-
mation to the IDE using the configured serial link. For Emulator based debugging, Keil IDE acts as an
 Introduction to Embedded Systems

interface between a Keil supported third party Emulator hardware and the target board. The Serial link
should be connected to the emulator hardware and other end of the emulator hardware should be inter-
faced to the target hardware using any ICE supported interfaces like JTAG, BDM or pin-to-pin socket
(For JTAG/BDM interface, target proces.sor/controller should have this support at processor/controller
side. If not, pin-to-pin socket is used).✓ t '
13.1.1.4 Writing JSR in Embedded C using the µVision3 IDE The C51 cross-compiler from
Keil supports the implementation of Interrupt Service Routines (ISRs) in Embedded C. The general
form of writiqg an Interrupt Service Routine:,in C for C51 cross-compiler is illustrated below.

1
,)

The attribute interrupt informs the cross compiler that the function with given name (Here JSR_
Name) is an Interrupt Service Routine. The attribute INTR_NO indicates the interrupt number for an
interrupt. It is essential for placing the ISR generated assembly code at the Interrupt Vector for the cor-
responding interrupt. Keil supports 32 ISRs for interrupt number$ 0 to 31. The interrupt number Ocor-
responds to External Interrupt 0, 1 corresponds to Timer OInterrupt, 2 correspondis tQ External Interrupt
1, 3 corresponds to Timer 1 Interrupt, 4 corresponds to Serial Interrupt and so on. The keyword using
specifies the Register bank mentioned in the attribute REG_BANK for the registers RO to R7 inside the
ISR. It is an optional attribute and if it is not mentioned in the ISR implementation, the current register
bank in use by the controller is used by the ISR for the registers RO to .R7. The value of REG_BANK can
vary from Oto 3, representing register banks Oto 3. With the attribute interrupt, the CS 1 cross compiler
automatically generates the interrupt vector and entry and exit code for the specified interrupt routine.
The contents of the Accumulator, B register, DPH, DPL, and PSW are Pushed to the stack as and when
required, at the time of entering the ISR and are retrieved at the time of leaving the ISR. If the register
bank is not specified in the ISR implementation, all the working registers which are modified inside the
ISR is pµshed to the stack and poped while returning from ISR. It should be noted that the ISR neither
takes any parameter nor return any. The following piece of code illustrates the implementation of the
Serial Interrupt ISR for 8051 using C5 l cross compiler.
tinclude <reg51.h> / C51 Header file
/ /ISR for handling Serial Interrupts. Int,errupt number 4
//Interrupt Vector at 0023H. Use Register Bank 1

· voif Serial_ISR (void) interrupt ·4 using 1

, { '

if (TI) //Check transmit (TI) Flag

{
//Transmit Interrupt Handler
}
else
{
Interrupt Handler
 \.

The Embedded System Development Environment

13.1.1. 5 Assembly Based Firmware Development with µ Vision3 IDE Apart from Embedded
C based development, Keil IDE also supports Assembly language based firmware development. The
steps involved in creating a project for writing assembly instructions are same as that of Embedded C
based development. The only difference is that there is no need to include the standard startup file at
the time of creating a project. Select the option 'No' to the query 'Copy standard 8051 startup Code to
Project Folder and add File to Project?' while creating a new project (Refer to Sectio!l-13 .1.1 for details
on creating a new project). Since we are not using the IDE supplied startup code, thEili~ctions performed
by startup code (mainly initia}isation of. stack pointer), should be written by the progrart}mer before the
start of the main program in the assem):ily file. Create a new file and start writing Asse~ly instructions
in the file. Save the file with extension '.src' and add the file to the 'Source Group' o~ the target as il-
lustrated in embedded C based development (Section 13 .1.1 ). A program written in Assembly Language
corresponding to the "Hello World" program written in Embedded C is illustrated below.
.
;##.##HJ##ff##U#~##~####Hfi#JJ##O#UU##J##JJ#U##U#j/:fU##HOU## .
.{ . . ' ·. ·,.I ··: , ·. . · · . .. sfaif .ifr'CMiiA ecP.b~~i~~ .· .. ·\· _· . ·· · ' ·i. · " ( ·. .
.; #Ut,# #f# tH #it### #,~ltJtF,f# ## # #l#fififf#lJt*"tiil## ##tf# #*##HU#'#####)#$}# jf
oRG booo'H ·
.JMP MAIN
; External Interi.upt (') .ffa.rn:ij.lex
RETI
; Tlmer0 ,Interrupt ·Hand.fer
RETI
. \ .. .
; '!'.lxterrial 'Int;er;rupt l'Hahdler,
REn
-ORG . Q0}BH · Timed
,. /":>,.' .· •
Int~rrupt',Hancfl!=:r,
. .; , '
'~

RET1
0023H. ) S_erial Interrup:t 'Handl,er
RE'rT
ORG 6l'00H ,
MAIN: MOV SP, #S0H ; Initialise stack pointer ,50H
; ###############################################UH#################
; 8051 Serial Routine Parameter seitin~s
MOV SCON·, Jf 50h Configure Serial Communication
Register.
MOV TMOD, #21h Baud Generation Settings
MOV THl, #0FDH Re-Load Value for TIMER 1 in Auto
Re-Load
MOV TLl, #0FDH 9600 baud
MOVA, PCON
ANL A, #7FH
MOV PCON, A
SETB TRl ; Start Timerl
;###########!########################################################
OUT TEXT: CALL _TEXT_OUT
JMP OUT TEXT
;####################################################################
Text outputting Routine
; Same as pr.intf () in Embedded C
 Introduction to Embedded Systems

T]~XT...:.O,UT;., MQY,,
~., ,
l)P'F,R:,
·,-; _,. ,., WORLD . ·.·
JHEJ,LO
'•--' .' ·/

f§~IA.L_OUT; CLR .TI ; ,Gle.ar Transm;i.t Inter:rupt.

-CLR ·A · , ., .
. .; MOVC A' @A+DPiJ:R h,.

cdNE: ;A: : #'\~·' io:GLOW ' .

:_ MOV ''SBUF' JfOiH •.
~
:serid new~,?~:,'1:bfe
' cl
Chara'.~ter.
/(.~~i;,.f:: ·~,
.\:?\'~ . : '. ·~~.., -;

. JMp. ·sER.tAt Gt:JT

' ,;fJi o~.ltttlJt tt't:uit:llh.iii,ifi .
'f ;~:r_;c;'~~:'1J1e ·. strii=lt[ ;ji'~'il~t;'r,WcJ:ii.a;~~f~
. kfttH/.if'flHt#iittfi#ilhiiOUlll:ft
HEiib ·woRLD = · •·, .
•l ,>(~:: .. t'~.•• ~ < "',r--· , '

h~:·''.'.: . 'Hello World\,

END

Compile this source code using the same compile options illustrated for Embedded C based develop-
ment. Here also you can have multiple source (.src) files. Add all source files to the 'Source Group' and
compile the program. The Assembly program is written to store the string "Hello World" in the code
memory and it is retrieved from the code memory for sending to the serial port. The string can also be
stor-ed-in the data memory and retrieve it from there for sending to the serial port. In that case the storage
memory for the string "Hello World" (12 bytes with string termination character'\') in the code memory
will be released and the same will occupy in the data memory. Figure 13.36 shows the assembling of
source code written in assembly language.
If you observe the output window while compiling, you can see that the source code is 'assembled'
instead of 'compiling'. Why this strange thing happens? - The answer is conversion of program writ-
ten in assembly language to object code is carried out by. the utility 'Assembler'. Assembler is same as
compiler in functioning but the input is different. You can debug this application usin~ the simulator in
a similar way as that of debugging the 'C' source code. On debugging the assembly code you can view
the output on the 'Serial-Window' and it is exactly the same as the output produced by the "Hello World''
Application written in Embedded C.
Now let's have a comparison between the application written in Embedded C and Assembly Lan-
guage for outputting the string "Hello World" to the Serial port. Read carefully.
Ql. How many lines of code you wrote for the program "Hello World"?
Embedded C: Only a single line of Code excluding the framework of main
Assembly: More than 25 lines
Q2. How many registers of the target processor you are familiar with for writing the "Hello
World" program?
Embedded C: None
Assembly: Almost all
 The Embedded System Development Environment

a ::::2
t i, Iii l
\ :ii~ ;1,"-:]Target 1
-"-",__:_:_:_:::_··_-·'-·--~-;'--·~--x_,F;..,._,,.. 0-1·-~~-------.. . . . .
'"i· ·B Source Group 1
J;] samp!e_asm.scc

RE'l'I
OOOBH

]ii] Build target 'Target 1'

i!i assembling sample_asiu.src ...
Codesize=321 bytes I
(;i linking ...
!t;'.i Program Size: data•B. xdata•O
~_;_.I "sample_asm" 0 Error(s ,
Data memory usage = 8 bytes
,Ji:
;::,1
;;~;=~====:;::._~..--~.-.-.. ~.~·.·• . . . -.. -.. . . . . . . . . . .
l!,__,,i_.c_~,;..
. :l~latio_n
,';=•'=:":=·-c::c:;::=,:;==;c;:=::'-' ::1:::=!:'::;:!.;'.''.,;=c·=l=·".F~~
j,, '· ·:----;:~ li52C:f3 , '

(@g>l3.36) Assembling ofsonrce code written in Assembly Langu<f.ge

. I
i
!,<' ·:- ...J
- ~j [§ OJ] t{} ~: ~ Se"all+1

Runn1nq with Code Size L1m1t: 2K

>
BreakKill BreakList

Ready

G~!9)3.37) Debugging the Source code mitten in Assembly Language.for outputting the text "Hello World" to
serial port
 Introduction to Embedded Systems

Q3. How many Assembly Instructions of the target processor you are familiar with for writing
the "Hello World'' program? 't
Embedded C: None
Assembly: Almost all '
Q4. What is the code size for the "Hello World" program written in? t
. Embedded C: l 078 bytes (

Assembly: 321 bytes

QS. What is the data memory size for the "Hello World" Progra,m written in?
Embedded C: 30 bytes + 1 bit 1
Assembly: 8 bytes Minimum and 21 Bytes Maximum (If the "Hello World" string is stored in Data (
memory)
Summary
1. Compared to Assembly programming, Embedded C requires lesser number of lines of code to
implement a task
2. Embedded C programmers require less or little knowledge on the internals of the target processor
whereas Assembly programmers require thorough knowledge of the internals of the processor
3. Embedded C programmers need not be aware of the instruction set of the target processor whereas
Assembly language programmers should be well versed in the same.
4. The Code memory usage by programs written in Assembly is optimal compared to the one written
in Embedded C
5. The Data memory usage by programs written in Assembly is optimal compared to the one written
in Embedded C
13.1.1. 6 Flash Memory Programming with Keil µVision3 IDE Once the firmware starts func-
tioning properly, after the modifications following debug and simulation, the next step is embedding the
firmware into the target processor/controller. As mentioned in a previous chapter, firmware can be em-
bedded using various techniques like Out of System Programming, In System Programming (ISP), etc.
Keil IDE provides an In System Programming (ISP) support which is selected at the time of configuring
the 'Options for Target'. It can be either Keil provided flash programming driver or any third party tool
which can be invoked from the IDE. The flash programming makes use of the serial connection estab-
lished between the Host PC and the target_ board. The target processor should contain a bootloader or a
monitor program which can understand the flash memory programming related commands sent from the
IDE. Cross-compile all the source files within the module,. link them and generate the binary code using
'Rebuild all target files' option. Download the generated binary file to the target processor's/controller's
memory by invoking 'Flash Download' option from the 'Project' tab of the IDE menu. The target board
should be powered and interfaced with the host PC where the IDE is running and the connection should
be configured properly.
13.1.1. 7 Summary of usage of Keil µVision3 IDE So far we discussed 'about IDE and how IDE
is helpful in Embedded application development and debugging. Our discussion was focusing only on
8051 family 8bit microcontroller firmware application development using Keil µ Vision3 IDE. Though
the discussion Was specific to Ke~l IDE, I believe it was capable of g1~i~o/you the basic fundas ofIDEs
and how the IDE is used in embedded system development. The hot €rJ usage, GUI details and func-
tions offered by different IDEs are totally different. Illustrating all ID slis out: of scope of this book and
also there is~ommon IDE supporting multiple ~amily devices-that c~n bf 'used fo~ illustrating the
same.. Users are requested to go through the respective manuals of the IDE thty ard1smg for firmware
, development. Also, IDEs undergo rapid changes by adding new features, functions, etc. and whatever
'
1
The Embedded System Development Environment

we discussed here need not be the same after three months or six months or one year, in terms of fea-
tures, UI, hot keys, menu options, etc. When I sta11ed the work of this book, the IDE offered from Keil
was Keil µVision2 and at the time of finishing this work, the latest IDE available from Keil is Keilµ Vi-
sion3. It incorporated lots of new features and changes compared to the old IDE. Users are requested
to visit the web site wvlw.keil.@m to get the latest updates on the new versions of the IDE. You can
directly download the trial version of the IDE from the above site.
. .
13.1.2 An Overview ~fIDEs for Embedded System Development
The table shown below gives an overview of the Integrated Development Environments (IDEs) used for
developing embedded systems for various processors/Real-time operating systems.

Atmel <:orp~~iition . . .. . ;!:;, . . .. . .

· llttp :/fm.~tmcl.com/dyn/Products/tools catci'.~?tool >ii~·~ ·
id=2725 ·: ...•. . / .- "'

Keil Software, A,n .A1Uv1 Co11ipa~yt

1~ttp:11~mv.k~iLcort1J~ftn1 C < .•·· •

ARM IAR Embedded Workbench lAR Systems

for ARM http://www.iar.com/websitel/l .O. l .0/68/l/index.phJ)
Co~eWi!Jior Freescale Semiconductor
http://~]:ree;cale.c~m/ . " ,,,., •,•.,,

. ' '"
ARM Sourcery G++ CodeSourcery
http://www.codesourcery,.g.mn/.,gnu toolchain~
It is a complete software development envirnnmentbas~~ .,
on the GNU Tool chain. Soutcery G++ includes the. (]N1,J ,
C and,C++ compilers, the Eclipse IDE. Supports ARM®,
ColdFire®, fidoTM, MIPS®, Power Architecture™, ·
Stellarii®, x86 _
DAvE· ·•I:nfine~~T~chn9}ogies. For the 8, 16 and 3\!i,g.;
processorstcontrbllers. • . . :. ·•· ~
1mp://www.infi~eon.com/ · ·
 Introduction to Embedded Systems

Macraigo,r,Systems. EcHpse based GNU tool suite. \

And .... The list continues. There are thousands of ID Es available in the market as either commercial or
non-commercial and as either Open source tools or proprietary tools. --~= all of them is out of the
0

scope of this book. The intention is to just make the readers familiar with some of the popular ID Es for
some commonly used processors/controllers and RTOSs for embedded development.

Cross-compilation is the process of converting a source code writtyli in high level language (like 'Em-
bedded C') to a target processor/controller understandable machine code (e.g. ARM processor or 8051
microcontroller specific machine code). The conversion of the code is done by software running on a
processor/controller (e.g. x86 processor based PC) which is different from the target processor. The 1
software performing this operation is. referred as the 'Cross-compiler'. ln a single word cross-compila- ~
tion is the process of cross platform software/firmware development. Cross assembling is similar to ,l
cross-compiling; the only difference is that the code written in a target processor/controller specific J
Assembly code is converted into its corresponding machine code. The application converting Assembly ·1
instruction to target processor/controller specific machine code is known as cross-assembler. Cross- j
compilation/cross-assembling is carried out in different steps and the process generates various types of .!
intermediate files. Almost all compilers provide the option to select whatever intermediate files needs i
to be retained after cross-compilation. The various files generated during the cross-compilation/cross-
assembling process are:
List File (.lst), Hex File (.hex), Pre-processor Output.file, Map File (File extension linker dependent),
I

Object File (.obj)

 The Embedded System Development Environment

13.2.1 List File (.LST File)

Listing file is generated during the cross-compilation process and it contains an abundance of infonna-
tion about the cross compilation process, like cross compiler details, formatted source text ('C' code),
assembly code generated from the source file, symbol tables, errors and warnings detected during the
cross-compilation process. The type of infonnation contained in the list file is cross-compiler specific.
As an example let's consider the cross-compilation process of the file sample.c given as the first illus-
trative embedded C program under Keil µVision3 IDE discussion. The 'list file' generated contains the
following sections.
Page Header A header on each page of the listing file which indicates the compiler version number,
source file name, date, time, and page number.
cs1 ¢ai1Pr1ER~fa;t~'.f~~~t1i;c:,,.::. ·
Command Line Represents the entire command line that was used for invoking the compiler.

.~;i~~~~b.~!t\;~i~•t, it9
6.©MBILE
·~e·o'~i/;£/s~];,
Source Code The source code listing outputs the line number as well as the source code on that line.
Special cross compiler directives can be used to include or exclude the conditional codes (code in #if
blocks) in the source code listings. Apart from the source code lines, the list file will include the com-
ments in the source file and depending on the list file generation settings the entire contents of all include
files may also be included. Special cross compiler directives can be used to include the entire contents
of the include file in the list file.
line level source
1 //Sample.c for printing Hello World!
2 //Written by xyz
3 #include <stdio.h>
1 -1 /*--------------------------------------------------------------------------
2 =l STDIO.H
3 =l
4 Prototypes for standard I/O functions.
5 Copyright© 1988-2002 Keil Elektronik GmbH and Keil Software, Inc.
6 =1 All rights reserved.
7 -1 --------------------------------------------------------------------------*/
8
9 #ifndef STDIO H
10 =l #define STDIO H
11 =l
12 =l #ifndefEOF
13 =l #define EOF -1
14 #endif
15 =l
16 =1 #ifndef NULL
 Introduction to Embedded Systems

17 =1 #define NULL ((void *) 0)

18 =1 #endif
19
20 =1 #ifndef - SIZE-I T
21 =1 #define - SIZE T
22 := 1 typedef unsigned int size t;
23 =1 #endif
24
25 = 1 #pragma SAVE
26 #pragma REGPARMS
27 =1 extern char _getkey (void);
28 =1 extern char getchar (void);
. 29 extern char ungetchar (char);
30 =1 extern char putchar (char);
31 extern int printf canst char *, ... );
1
(

32 =1 extern int sprintf (char *, canst char *, ... );

33 =1 extern int vprintf (const char *, char *);
34 extern int vsprintf (char *, const char *, char *);
35 =1 extern char *gets (char *, int n);
36 =1 extern int scanf (canst char *, .. );
37 =1 extern int sscanf (char*, canst char*, ... );
38 =1 extern int puts (const char*);
39
40- =1 #pragma RESTORE
41 =l
42 =1 #endif
43 =1
4
5 voidmainO
6 {'
7 1 printf("Hello Worldl\n");
8 1 }
9
Assembly Listing Assembly listing contains the assembly code generated by the cross compiler for
the 'C' source code. Assembly code generated can be excluded from the list file by using special com-
piler directives.
AS~EMBLY LISTING OF GENERATED OBJECT CODE
; FUNCTION main (BEGIN)
; SOURCE LINE# 5
; SOURCE LINE# 6
; SOURCE LINE # 7
0000 7BFF MOV R3, #0FFH
0002 7A00 R MOV R2, #HIGH ?SC_0
l
l
l\
The Embedded System Development Environment

l
0004 7900 R MOV Rl, #LOW ?SC_0
I 0006 040000 E LJMP . _printf

l ; FUNCTION main (END)

Symbol Listing The symbol listing contains symbolic information about the-various.symbols present
in the cross compiled source file. Symbol listing contains the sections symbol name {NAME) symbol
classification (CLASS (Special Function Register (SFR), structure, typedef, static, public, auto, extern,
etc.)), memory space (MSPACE (code memory or data memory)), data type (TYPE" (int; char, Procedure
call, etc.)), offset ((OFFSET from code memory start address)) and size in bytes (SIZE). Symbol listing
in list file output can be turned on or off by cross-compiler directives.
I
NAME CLASS MSPACE TYPE OFFSET SIZE
--- -- ---
size_t ..... TYPEDI;:F U INT ----- 2
main .......PUBLIC . CODE PROC OOOOH .,. ____
_printf...... EXTERN CODE PROC
;
Module Information The module information provides the size of initialised and un-initialised
memory areas defined by the source file
MODULE INFORMATION: STATIC OVERLAYABLE
CODE SIZE 9
CONSTANT SIZE 14
XDATA SIZE =
PDATASIZE
DATA SIZE =
IDATASIZE =
BIT SIZE =
END OF MODULE INFORMATION.
Warnings and Errors Warnings and Errors section of list file records the errors encountered or any
statement that may create issues in application (warnings), during cross-compilation. The warning lev-
els can be configured before cross compilation. You can ignore certain warnings, e.g. a local variable is
declared within a function and it is not used anywhere in the program. Certain warnings require prompt
attention.

List file is a very useful tool for application debugging in case of any cross compilation issues.

13.2.2 Preprocessor Output File

The preprocessor output file generated during cross-compilation contains the preprocessor output for
the preprocessor instructions used in the source file. Preprocessor output file is used for verifying the
operation of macros and conditional preprocessor directives. The preprocessor output file is a valid C
source file. File extension of preprocessor output file is cross compiler dependent.
 Introduction to Embedded Systems

13.2.3 Object File (.OBJFile)

Cross-compiling/assembling each source module (written in CfAssembly) converts the various Embed-
ded Cl Assembly instructions and other directives present in the module to an object (. OBJ) file. The
format (internal representation) of the .OBJ file is cross compiler dependent. OMF51 or OMF2 are the
two objects file formats supported by C51 cross compiler. The object file is a specially formatted file
with data records for symbolic information, object code; debugging information, library references, etc.
The list of some of the details stored in an object file is given below.
1. Reserved memory for global variables.
2. Public symbol (variable and function) names.
3. External symbol (variable and function) references.
4. Library files with which to link.
5. Debugging information to help synchronise source lines with object code.
The object code present in the object file are not absolute, meaning, the code is not allocated fixed
memory location in code memory. It is the responsibility of the linker/locater to assign an absolute
memory location to the object code. During cross-compilation process, the cross compiler sets the ad-
dress of references to external variables and functions as 0. The external references are resolved by the
linker during the linking process. Hence it is obvious that the code generated by the cross-compiler is
not executable without linking it for resolving external references.

13.2.4 Map File (.MAP)

As mentioned above, the cross-compiler converts each source code module into a re-locatable object
(OBJ) file. Cross-compiling each source code module generates its own list file. In a project with mul-
tiple source files, the cross-compilation· of each module generates a corresponding object file. The object
files so created are re-locatable codes, meaning their location in the code memory is not fixed. It is the
responsibility of a linker to link all these object files. The locater is responsible for locating absolute
address to each module in the code memory. Linking and locating of re-locatable object files will also
generate a list file called 'linker list file' or 'map file'. Map file contains information about the link/locate
process and is composed of a number of sections. The different sections listed in a map file are cross
compiler dependent. The information generally held by map files is listed below. It is not necessary that
the map files generated by all linkersilocaters should contain all.these information. Some may contain
less infonnation compared to this or others may contain more information than given in this. It all de-
pends on the linker/locater.
Page Header A header on each page of the linker listing (MAP) file which indicates the linker vei;,-
sion number, date, time, and page number.
e.g. BL51 LINKER/LOCATER V3.62 02/29/2004 09:59:51 PAGE 1

Command Line Represents the entire command line that was used for invoking the linker.
BL51 BANKED LINKER/LOCATEKy6.00, INVOKED BY:
C:\KEIL\C51\BIN\BL51. STARTUP. obj, . samp:).e .. obj '.I'O sampl~·
 The Embedded System Development Environment

CPU Details Details about the target CPU and memory model (internal data memory, external data
memory, paged data memory, etc.) come under this category.

Input Modules This section includes the names of all object modules, and library files and modules
that are included in the linking process. This section can be checked for ensuring all the required mod- ·
ules are lined in the li~ing proc_ess
e.g.

·Memory Map Memory map lists the starting address, length, relocation type and name of each
segment in the program.
e.g.
TYPE BASE .LENGTH RELOCATION SEGMENT NAME

* * * * * * ****** DAT A MEMORY * * * * * * ********

REG 0000H 0008H ABSOLUTE "REG BANKO"
DATA 0008H 0014H UNIT - DATA- GROUP
00ICH 0004H ***GAP***
BIT 0020H.0 000lH.l UNIT - BIT- GROUP
0021H.l 00O0H.7 ***GAP***
IDATA 0022H 0001H UNIT ?STACK
* * * * * * * ***** CODE MEMORY * * * * * * ********
CODE 0000H 0003H ABSOLUTE
0003H 07FDH ***GAP***
CODE 0800H 035CH UNIT ?PR?PRINTF?PRINTF
CODE 0B5CH 008EH UNIT ?C?LIB CODE
CODE 0BEAH 0027H UNIT ?PR?PUTCHAR?PUTCHAR
CODE 0CllH 00OEH UNIT ?CO?SAMPLE
CODE 0ClFH 000CH UNIT ?C C51STARTUP
CODE 0C2BH 0009H UNIT ?PR?MAIN?SAMPLE
Symbol Table It contains the value, type and name for all symbols from the different input
modules
 Introduction to Embedded Systems
li
e.g.
SYMBOL TABLE OF MODULE: sample (?C_START,UP)

VALUE TYPE NAME

---------------------------------------------------------
MODULE ?C STARTUP i

C:0ClFH SEGMENT ?C C51STARTUP

I:0022H SEGMENT ?STACK 1
C:0000H PUBLIC ?C STARTUP
D:00E0H SYMBOL ACC
D:00F0H SYMBOL B
D:0083H SYMBOL DPH
D:0082H SYMBOL DPL
Inter Module Cross Reference The cross reference listing includes the section name, memory type
and the name of the modules in which it is defined and all modules in which it is accessed.
e.g.
NAME .................. USAGE MODULE NAMES

?C?CCASE ............ CODE; ?C?CCASE PRINTF

?C?CLDOPTR ........ CODE; ?C?CLDOPTR PRINTF
?C?CLDPTR ............. CODE; ?C?CLDPTR PRINTF
?C?CSTPTR...............CODE; ?C?CSTPTR PRINTF
?C?PLDIIDATA ....... CODE; ?C?PLDIIDATA · PRINTF
Program Size Program size information contain the size of various memory areas as well as constant
and code space for the entire applicati?n
e.g. Program Size: data=30.l xdata=O code=l079

Warnings and Errors Errors and warnings generated while linking a program are written tp this
section. It is very useful in debugging link errors:
e.g. LINK/ LOCATE RUN COMPLETE • 0 WARN ING (S) , 0. ~RROR CS)

NB: The file extensio~ for.MAP file$'.Sf?)lff'1;t~,gt,f~ttt~reritJinkersllocaters nee4 n~t:be-the same.

It varies across linkerlltJcaterin. usfEpr exampl~themap'file generated for BL51 Linker/locater is
with extension .M5l · ·

13.2.5 HEX File (.HEX)

Hex file is the binary executable file created from the source code. The absolute object file created by the
linker/locater is converted into processor understandable binary code. The utility used for converting an
object file to a hex file is known as Object to Hex file converter. Hex files embed the machine code in
a particular format. The format of Hex file varies across the family of processors/controllers. Intel HEX
and A1otorola HEX are the two commonly used hex file formats in embedded applications. Intel HEX
file is an ASCII text file in which the HEX data is represented in ASCII format in lines. The lines in an
 The Embedded System Development Environment

Intel HEX file are corresponding to a HEX Record. Each record is made up of hexadecimal numbers that
represent machine-language code and/or constant data. Individual records are terminated with a carriage
return and a linefeed. Intel HEX file is used for transferring the program and data to a ROM or EPROM
which is used as code memory storage.

13.2.5.1 Intel HEX File Format As mentioned, Intel HEX file is composed of a number of HEX
records. Each record is made up of five fields arranged in the following format:
:llaaaattdd... cc

Each group of letters corresponds to a different field, and each letter represents a single hexadecimal
digit. Each field is composed of at least two hexadecimal digits (which make up a byte) as described
below:

extract from the Intel hex file generated for "Hello World" application example is given below.
:03000000020C1FDO
:OCOC1F00787FE4F6D8FD758121020C2BD3
:OEOC l 10048656C6C6F20576F726C64210A008E
:090C2B007BFF7AOC79 l 1020862CA
:10080000E517240BF8E605 l 7227808300702780B65
:1008fOOOE475FOO l 120BB4020B5C2000EB7F2ED2CA
:10082000008018EF540F2490D43440D4FF30040BDO
: l 0083000EF24BFB41A0050032461FFE518600215CD
:100840001805 IBE51B7002051A30070D7808E475C2
:100BFAOOB.8130CC2983098FDA899C298B811F6306B
:070COA0099FDC299F5992242 . .
:OOOOOOOIFF
Let's analyse the first record

0 3 0 0
 ·,ff
. •. ,r

'j,
j
~
Introduction to Embedded Systems

: field indicates the start of a new record. 03 (ll) gives the number of data bytes in the record. For this
record,' ll' is 03 and the number of data bytes in the corresponding record is 03. The start address (aaaa)
of data in the record is 0000H. The record type byte (tt) for this record is 00 and it indicates that this
record is a data record. The data for the above record is 02, 0C and IF. They are supposed to place at
three consecutive memory locations in the EEPROM with starting address Q000H. The arrangement is
given below.

If you are familiar with 8051 Machine code you can easily identify that 02 is the machine code for
the instruction LJMP and the next two bytes represent the 16bit address of the location to which the
jump is intended. Obviously the instruction is LJMP OCJF. The last two digits (cc) of the record holds
the checksum of the values present in the record. The checksum is calculated by adding all the bytes in
the record and then taking modulo 256 of the result. The resultant is 2's complemented and represented
as checksum in the record field. Above example it is 0xDO. Intel hex files end with an end of file record
f
indicating the end of records in the hex file. Let's examine the end of record structure.
r
r
a
f
End of record also starts with the start of record symbol ': '. Since End of record does not contain any I,
data bytes, field 'll' will be 00. The field 'aaaa' is not significant since the number of data bytes are C
zero. Field 'tt' will hold the value OI to indicate that this record is an End ofrecord. Field 'cc' holds the 0
checksum of all the bytes present in the record and it is calculated as 2's complement of Modulo 256 of ti
(0 + 0 + 0 + 1) = 0xFF 1
ll
13.2.S.2 Motorola HEX File Format Similar to the Intel HEX file, Motorola HEX file is also an
0
ASCII text file where the HEX data is represented in ASCII format in lines. The lines in Motorola HEX
d
file represent a HEX Record. Each record is made up of hexadecimal numbers that represent machine-
fi
language code and/or constant data. The general form of Motorola Hex record is given below.
SOR··
v"J.
RT
In other words it can be represented as Stllaaaaddddd ... cc
The fields of the record are explained below. I
Cr

Des~ription · S(
'',t_,;/.',H'' ,- \,,,;,,,,,

SOR Stands for S_tart.. · ·· · · d. -:rhe:ASC IS

D
fr
re

b(
rn

j
 The Embedded System Development Environment

You can see that each Record starts with the ASCII character 'S'. For the first record, the value for
field 't' is 0 and it implies that this record is the first record in the hex file (Header Record). The second
record is a data record. The field 't' for second record is 1. Number of character pairs held by second
record is 0x13 (19 in decimal). Out of this two character pairs are used for holding the start address
and one character pair for holding the checksum. Rest 16 _bytes are the data bytes. The start address for
placing the data bytes is 0xll00. The data bytes that are going to be placed in 16 consecutive memory
locations starting from address 0xll00 are 0x00, 0x02, 0x00, 0x08, 0x00, 0x08, 0x26, 0x29, 0x00;--
0x18, 0x53, 0x81, 0x23, 0x41, 0x00 and 0xl8. The last two digits (here 0x12) represent the checksum
of the record. Checksum is calculated as the least significant byte of the one's complement of the sum of
the values represented by the pairs of characters making up the record length, address, and data fields.
The third record represents the End of File record. The value for field 't' for this record is 9 and it is an
indicative of End of Hex file. Number of character pairs held by this record is 03; two for address and
one for the checksum. The address is insignificant here since the record does not contain any values to
dump into memory. Only one End of File Record is allowed per file and it must be the last line of the
file.

13.3 DISASSEMBLER/DECOMPILER
Disassembler is a utility program which converts machine codes into target processor specific Assembly
codes/instructions. The process of converting machine codes into Assembly code is known as 'Disas-
sembling'. In operation, disasseri1bling is complementary to assembling/cross-assembling. Decompiler
is the utility program for translating machine codes into corresponding high level language instructions.
Decompiler performs the reverse operation of compiler/cross-compiler. The disassemblers/decompilers
for different family of processors/controllers are different. Disassemblers/Decompilers are deployed in
reverse engineering. Reverse engineering is the process of revealing the technology behind the working
of a product. Reverse engineering in Embedded Product development is employed to find out the secret
behind the working of popular proprietary products. Disassemblers/decompilers help the reverse-engi-
neering process by translating the embedded firmware into Assembly/high level language instructions.
 Introduction to Embedded Systems
l
1l
iI

Disassemblers/Decompilers are powerful tools for analysing the prysence of malicious codes (virus
li
I
information) in an executable image. Disassemblers/Decompilers are available as either freeware tools
readily available for free download from internet or as commercial tools. It is not possible for a disas-
sembler/decompiler to generate an exact replica of the original assembly code/high level source code
in terms of the symbolic constants and comments used. However disassemblers/decompilers generate
a source code which is somewhat matching to the original source code from which the binary code is
generated.

Simulators and emulators are two important tools used in embedded system development. Both the
terms sound alike and are little confusing. Simulator is a software tool used for simulating the various
conditions for checking the functionality of the application firmware. The Integrated Development En-
vironment (IDE) itself will be providing simulator support and they help in debugging the firmware for
checking its required functionality. In certain scenarios, simulator refers to a soft model (GUI model)
of the embedded product. For example, if the product under development is a handheld device, to test
the functionalities of the various menu and user interfaces, a soft form model of the product with all UI
as given in the end product can be developed in software. Soft phone is an example for such a simulator.
Emulator is hardware device which emulates the functionalities of the target device and allows real time
debugging of the embedded firmware in a hardware environment.

13.4.l Simulators
In a previous section of this chapter, describing the Integrated Development Environment, we discussed
about simulators for embedded firmware debugging. Simulators simulate the target hardware and the
firmware execution can be inspected using simulators. The features of simulator based debugging are
listed below.
1. Purely software based
2. Doesn't require a real target system
3. Very primitive (Lack of featured I/O support. Everything is a simulated one)
4. Lack of Real-time behaviour
13.4.1.1 Advantages of Simulator Based Debugging Simulator based debugging techniques
are simple and straightforward. The major advantages of simulator based firmware debugging techniques
are explained below.
No Need for Original Target Board Simulator based debugging technique is purely software ori-
ented. IDE's software support simulates the CPU of the target board. User only needs to know about the
memory map of various devices within the target board and the firmware should be written on the basis
of it. Since the real hardware is not required, firmware development can start well in advance immedi-
ately after the device interface and memory maps are finalised. This saves development time.
Simulate 110 Peripherals Simulator provides the option to simulate various I/O peripherals. Us-
ing simulator's I/O support you can edit the values for I/O registers and can be used as the input/output
value in the firmware execution. Hence it eliminates the need for connecting I/O devices for debugging
the firmware.

I
 The Embedded System Development Environment

l Simulates Abnormal Conditions With simulator's simulation support you can input any desired
value for any parameter during debugging the firmware and can observe the control flow of firmware. It
really helps the developer in simulating abnormal operational environment for firmware and helps the
firmware developer to study the behaviour of the firmware under abnormal input conditions.
13A. 1.2 Limitations .of Simulator based Debugging Though simulation based firmware de-
bugging technique is very helpful in embedded applications, they possess certain limitations and we
cannot fully rely ~pon·the s_imulator-based firmware debugging. Some of the limitations of simulator-
based debugging are expla_ined below.
Deviation from Real Behaviour Simulation-based firmware debugging is always carried out in a
development environment where the developer may not be able to debug the firmware under all possible
combinations of input. Under certain operating ~onditions we may get some particular result and it need
not be the same when the-firmware runs in a production environment.
Lack of real timeliness The major limitation of simulator based debugging is that it is not real-time
in behaviour. The debugging is developer driven and it is no way capable of creating a real time behav-
iour. Moreover in a real application the I/0 condition may be varying or unpredictable. Simulation goes
for simulating those conditions for known values.

13.4.2 Emulators and Debuggers

What is debugging and why debugging is required? Debugging in embedded application is the process
of diagnosing the firmware execution, monitoring the target processor's registers and memory while the
firmware is running and checking the signals from various buses of the embedded hardware. Debugging
process in embedded applicat1on is broadly classified into two, namely; hardware debugging and firm-
'"' ware debugging. Hardware debugging deals with the monitoring of various bus signals and checking
Hr the status lines of the target hardware. The various tools used for hardware debugging will be explain-
ing in detail in a later section of this chapter. Firmware debugging. deals with examining the firmware
execution, execution flow, changes to various CPU registers and status registers on execution of the
fitmware to ensure that tl,ie firmware is running as per the design. This section deals with the debugging
of firmware.
Why is debugging required? Well the counter question why you go for diagnosis when you are ill
answers this query. Firmware debugging is performed to figure out the bug or the error in the firmware
which creates the unexpected behaviour. Finnware is analogous to the human body in the sense it is
widespread and/or modular. Any abnormalities in any area of the body may lead to sickness. How is
the region causing illness identified correctly when you are sick? If we look back to the 1900s, where
no sophisticated diagnostic techniques were available, only a skilled doctor was capable of identifying
the root cause of illness, that too with his solid experience. Now, with latest technologies, the scenario
is totally changed. Sophisticated diagnostic techniques provide offline diagnosis like Computerized
Tomography (CT), MRl and ultrasound scans and online diagnosis like micro camera based imaging
techniques. With the intrusion of a micro camera into the body, the doctors can view the internals of the
body in real time. ..
During the early days of embedded system development, there were no debug tools available and
the only way was "Burn the code in an EEPROM and pray for its proper functioning". If the firmware
does not crash, the product works fine. If the product crashes, the developer is unlucky and he needs
to sit back and rework on the finnware till the product functions in the expected way. Most of the time
 Introduction to Embedded Systems

the developer had to seek the help of an exp_e_rt to figure out the exact problem creator. As technology
has achieved a n_~W dimension from the early days of embedded system development, various types of
debugging technkiues are available today. The following section describes the improvements over firm-
ware debugging starting from the most primitive type of debugging to the most sophisticated On Chip
Debugging (OCD).
13.4.2.1 Incremental EEPROM Burning Technique This is the most primitive type of firmware
debugging technique where the code is separated into different functional code units. Instead of burning
the entire code into the EEPROM chip at once, the code is burned in incremental order, where the code
corresponding to all functionalities are separately coded, cross-cqmpiled and burned into the chip one
by one. The code will incorporate some indication support like lighting up an "LED (every embedded
product contains at least one LED). If not, you should irn;lude provision for at least one LED in the
target board at the hardware design time such that it can be used for debugging purpose)" or activate a
"BUZZER (In a system with BUZZER support)" if the code is functioning in the expected way. If the
first functionality is found working perfectly on the target board with the corresponding code burned
into the EEPROM, go for burning the code corresponding to the next functionality and check whether
itis working. Repeat this process till all functionalities are covered. Please ensure that before entering
into one level up, the previous level has delivered a correct result. If the code corresponding to any
functionality is found not giving the expected result, fix it by modifying the code and then only go for
· adding the next functionality for burning into the EEPROM. After you found all functionalities working
prop(;rly, combine the entire source for all functionalities together, re-compile and bum the code for the
total $Y$teri:l functioning.
Obviously it is a time-consuming process. But remember It is a onetime process and once you test
the firmware in an incremental model you can go for mass production. In incremental firmware burning
technique we are not doing any debugging but observing the status_of firmware execution as a debug
method. The very common mistake committed by firmware developers in developing non-operating
system-based embedded application is burning the entire code altogether and fed up with debugging
the code. Please don't adopt this approach. Even though you need to spend some additional time on
incremental burning approach, you will never lose in the process and will never mess up with debug-
ging the code. You will be able to figure out at least 'on which point of firmware execution the issue
is arising' -"A stitch in time saves nine". Incremental firmV[are burning technique is widely adopted
in small, simple system developments and in product development where time is not a big constraint
(e.g. R&D projects). It is also very useful in product development environments where no other debug
tools are available.
13.4.2.2 lnline Breakpoint·Based Firmware Debugging Inline breakpoint based debugging is
another primitive method of firmware debugging. Within the firmware where you want to ensure that
firmware execution is reaching up to a specified point, insert an inline debug code immediately after
the point. The debug code is a printfO function which prints a string given as per the firmware. You can
insert debug codes (printfO) commands at each point where you want to ensure the firmware execution
is covering that point. Cross-compile thC' source code with the debug codes embedded within it. Burn
the corresponding hex file into the EEPROM. You can view the printfO generated data on the 'Hyper-
Terminal-A communication facility available with the Windows OS coming under the Comm,unica- 11

tions section of Start Menu' of the Development PC. Configure the serial communication settings of
the 'HyperTerminal' connection to the same as that of the serial communication settings configµred in j
the firmware (Say Baudrate = 9600; Parity= None; Stop Bit= 1; Flow Control= None); Connect the

l.
Ij
The Embedded System Development Environment
·1
I
I
li target board's serial port (COM) to the development PC's COM Port using an RS232 Cable. Power up
] the target board. Depending on the execution flow of :firmware and the inline debug codes inserted in the
1 firmware, you can view the debug information on the 'Hyper Terminal'. Typical usage of inline debug
i codes and the debug info retrieved on the HyperTerminal is illustrated below.
l'tJt~st 1nr<frj~ Bel:irtrg Gode ·· • '. 0
· ·· r-~;~~t~;ifJ9 ';~9~{i94t~~Jf~;·ti!~l!{;t;.

If the firmware is error free and the execution occurs properly, you will get all the debug messages on
~he HyperTerminal. Based on this debug info you can check the :firmware for errors (Fig. 13.38) .

. Starting Configuration .. .
End of Configuration .. .
.!Beginning of Firmware Execution ...
End of Code segment 1 .. .
End of Code segment 2 .. .

( Fig.13.38) lnline Breakpoint Based Firmware Debugging with HyperTerminal

 Introduction to Embedded Systems

13.4.2.3 Monitor Program Based Firmware Debugging Monitor program based firmware de-
bugging is the first adopted invasive method for firmware debugging (Fig. 13.39). In this approach a so
monitor program which acts as a supervisor is developed. The monitor program controls the download- su;
ing of user code into the code memory, inspects and modifies register/memory locations; allows single lo,
stepping of source code, etc. The monitor program implements Jhe debug functions as per a pre-defined Th
co~and set fro~ the debug a~plication interfac;e: The n:ioni~r program a_lw~ys listens_ to the serial port pn.
of the target device and accordmg to the command received from the senal mterface 1t performs com- of
mand specific actions like firmware downloading, memiiy inspection/modification, firmware single RJ
stepping and sends the debug information (various register and memory contents) back to the main de- cir
bug program running on the de,velopment PC, etc. The first step in any monitor program development is th~
petermining a set of commands for performing various operations like firmware downloading, memory/ loe ·
register inspection/modification, single stepping, etc. Once the commands for each operation is fixed, . chi·
write the co.de for.performing the actions corresponding fo these commands. As mentioned earlier, the rrie •
coiµmarids may be received through any of the external interface of the target processor (e.g. RS-232C of
serial interface/parallel interface/USE, etc.). The monitor program should query this interface to get tak
commands or should handle the command reception if the data reception is implemented through inter- , ba1
rupts. On receiving a command, examine it and perform the action corresponding to it. The entire code Th
stuff handling the command reception and corresponding action implementation is known as the "moni- the
tor program". The most common type of interface used between target board and debug application is RA
RS-232C Serial interface. After the successful completion of the 'monitor program' development, it is de,
compiled and burned into the FLASH memory or ROM of the target board. The code memory contain- mo
ing the monitor program is known as the 'Monitor ROM.

Target CPU

RS-232 Serial link

,.
L

Target board
~
:I
,,

Von-Neumann RAM 13.

'En
( Fig. 13.39) Monitor Program Based Target Firmware Debug Setup "'
i me1
The monitor program contains the following set of minimal features. l and
1. Command set interface to establish communication with the debugging application
2. Firmware download option to code memory
3. Examine and modify processor registers and working memory (RAM)
4. Sjngle step program execution
l lS a
nee
on1
Sill
5. Set breakpoints in firmware execution
6. Send debug information to debug application running on host machine '
'
..
wer

lI
I
I The Embedded System Development Environment

The monitor program usually resides at the reset vector (code memory 0000H) of the target proces-
sor. The monitor program is commonly employed in development boards and the development board
supplier provides the monitor prograµ\ in the form of a ROM chip. The actual code memory is down-
l9aded into a RAM chip which is ip.terfaccd to the processor in the Von-Neumann architecture model.
The Von-Neumann architecture model is achieved by ANDing the PSEN\ and RD\ signals of the target
processor (In case of 8051) and connecting the output of AND Gate to the Output Enable.(RD\) pin
of RAM ch1p. WR\ signal of the target processor is interfaced to The WR\ signal of the Von Neuma111).
RAM. Monitor ROM size varies in the range of a few kilo bytes (Usually 4K). Ari address decoder
circuit maps the a~dress range allocated to the monitor ROM and activates the Chip Select (CS\) of
the ROM.if the address is within the range specified for the Monitor ROM. A user program is normally
-loaded at locations 0x4000 or 0x8000. }'he.address decoder circuit ensures the enabling of tae RAM·
chip (CS\) when the :address range is outside that allocated to the ROM monitor. Though there are two
niemory chips (Monitor ROM Chip and Von~Neutnann RAM), the total memory map ivailable for both
of them will be 64K for a processor/controller with 16bit address spice.and-the memory decoder1units
take care of avoiding conflicts in accessing both. While developing user program for rrionhor ROM-
, based systems, special care should be taken to offsetthe user code.,and handling·the interrupt vectors.
The target development IDE will help in resolving this. During firmware execution and single stepping,
the user code may have to ~e altered and hence the firmware is always downloaded into a Von:.Neumann
RAM in monitor ROM-based debugging systems. Monitor ROM-based debugging is suitable only for
development work and it is not a good choice for mass produced systems. The major drawbacks of
monitor based debugging system are
1. The entire memory map is converted into a Von-Neumann model and it is shared between the
monitor ROM, monitor program data memory, monitor program trace buffer, user written firm-
ware and external user memory. For 8051, the original Harvard architecture supports 64K code
memory and 64K external data memory (Total 128K memory map). Going for a monitor based
debugging shrinks the total available memory to 64K Von-Neumann memory and it needs to ac-
commodate all kinds of memory requirement (Monitor Code, monitor data, trace buffer memory,
User code and External User data memory).
2. The communication link between the debug application rum1ing on Development PC and monitor
program residing in the target system is achieved through a serial link and usually the controller's
On-chip UART is used for establishing this link. Hence one serial port of the target processor be-
\~ comes dedicated for the monitor application and it cannot be used for any other device interfacing.
Wastage of a serial port! It is a serious issue in controllers or processors with single UART.
~
l 13.4.2.4 In Circuit Emulator (ICE) Based Firmware Debugging The terms 'Simulator' and
I 'Emulator' are little bit confusing and sounds similar. Though their basic functionality is the same
'j - "Debug the target firmware", the way in which they achieve this functionality is totally different. As
l· mentioned before, 'Simulator' is a software application that precisely duplicates (mimics) the target CPU
a_ and simulates the various features and instructions supported by the target CPU, whereas an 'Emulator'
I is a self-contained hardware device which emulates the targ~t CPU. The emulator hardware contains
necessary emulation logic and it is hooked to the debugging application running on the development PC
on one end and connects to the target board through some interface on the other end. In summary, the
\: simulator 'simulates' the target board CPU and the emulator 'emulates' the target board CPU.
There is a scope change that has happened to the definition of an emulator. In olden days emulators
were defined as special hardware devices used for emulating the functionality of a processor/controller
 Introduction to Embedded Systems

and perfomiing various debug operations like halt firmware execution, set breakpoints, get or set inter-
nal RAM/CPU register, etc. Nowadays pure software applications which perfomi the functioning of a
hardware emulator is also called as 'Emulators' (though they are 'Simulators' in operation). The emula-
tor application for emulating the operation of a PDA phone for application development is an example
of a 'Software Emulator'. A hardware emulator is controlled by a debugger application running on the
development PC. The debugger application may be part of the Integrated Development Environment
(IDE) or a third party supplied tool. Most of the ID Es incorporate debugger support for some of the
emulators commonly available in the market. The emulators for different families of processors/con-
trollers are different. Figure 13.40 illustrates the different subsystems and interfaces of an 'Emulator'
device.

Debugger application RS-232/USB cable Emulator POD

!------{----------, I
I l Target board interface
I
I . (Device adaptor)
I / :I
. '· ·' ,. .. >.

:in circuit emulator /

-- -- ---f--
Signal lines
PC COM/USB port
(Flat Cable)

The Emulator POD forms the heart of any emulator system and it contains the following functional
units.
Emulation Device Emulation device is a replica of the target CPU which receives various signals
from the target board through a device adaptor connected to the target board and perfomis the execution
of firmware under the control of debug commands from the debug application. The emulation device
can be either a standard chip same as the target processor (e.g. AT89C5 l) or a Programmable Logic
Device (PLD) configured to function as the target CPU. If a standard chip is used as the emulation de-
vice, the emulation will provide real-time execution behaviour. At the same time the emulator becomes
dedicated to that particular device and cannot be re-used for the derivatives of the same chip. PLD-based
emulators can easily be re-configured to use with derivatives of the target CPU under consideration. By
simply loading the configuration file of the derivative processor/controller, the PLD gets re-configured
and it functions as the derivative device. A major drawback of PLD-based emulator is the accuracy of
replication of target CPU functionalities. PLD-based emulator logic is easy to implement for simple
target CPUs but for complex target CPUs it is quite difficult.
Emulation Memory It is the Random Access Memory (RAM) incorporated in the Emulator device.
It acts as a replacement to the target board's EEPROM where the code is supposed to be downloaded
after each finnware modification. Hence the original EEPROM memory is emulated by the RAM of
emulator. This is known as 'ROM Emulation'. ROM emulation eliminates the hassles of ROM burning
and it offers the benefit of infinite number of reprogrammings (Most of the EEPROM chips available
 The Embedded System Development Environment

in the market supports only 100 to 1000 re-program cycles). Emulation memory also acts as a trace
buffer in debugging. Trace buffer is a memory pool holding the instructions exec1Jted/registers modi-
fied/related data by the processor while debugging. The trace buffer size is emulator dependent and the
trace buffer holds the recent trace information when the buffer overflows. The common features of trace
buffer memory and trace buffer data viewing are listed below:
• Trace buffer records each bus cycle in frames
• Trace data can be viewed in the debugger application as Assembly/Source code
• Trace buffering can: be·done on the basis of a Trace trigger (Event)
• Trace buffer can also record signals from target board other than CPU signals (Emulator depen-
dent)
• Trace data is a-very useful information in firmware debugging
Emulator Control Logic Emulator control logic is the logic circuits used for implementing complex
hardware breakpoints, trace buffer trigger detection, trace buffer control, etc. Emulator control logic
circuits are also used for implementing logic analyser functions in advanced emulator devices. The
'Emulator POD' is connected to the target board through a 'Device adaptor' and signal cable.
Device Adaptors Device adaptors act as an interface between the target board and emulator POD.
Device adaptors are normally pin-to-pin compatible sockets which can be inserted/plugged into the
target board for routing the various signals from the pins assigned for the target processor. The device
adaptor is usually connected to the emulator POD using ribbon cables. The adaptor type varies depend-
ing on the target processor's chip package. DIP, PLCC, etc. are some commonly used adaptors.
The above-mentioned emulators are almost dedicated ones, meaning they are built for emulating a
specific target processor and have little or less support for emulating the derivatives of the target proces-
sor for which the emulator is bunt. This type;,of emulators usually combines the entire emulation control
logic and emulation device (if present) in a single board. They are known as 'Debug Board Modules
(DBMs)'. An alternative method of emulator design supports emulation of a variety of target proces-
sors. Here the emulator hardware is partitioned into two, namely, 'Base Terminal' and 'Probe Card'.
The Base terminal contains all the emulator hardware and emulation control logic except the emulation
chip (Target board CPU's replica). The base terminal is connected to the Development PC for establish-
ing communication with the debug application. The emulation chip (Same chip as the target CPU) is
mounted on a separate·PCB and it is connected to the base terminal through a ribbon cable. The 'Probe
Card' board contains the device adaptor sockets to plug the board into the target development board.
The board containing the emulation chip is known as the 'Probe Card'. For emulating different target
CPUs the 'Probe Card' will be different and the base ter:minal remains the same. The manufacturer of
the emulator supplies 'Probe Card' for different CPUs. Though these emulators are capable of emulat-
ing different CPUs, the cost for 'Probe Cards' is very high. Communication link between the emulator
base unit/ Emulator POD and. debug application is established through a Serial/Parallel/USB interface.
Debug commands and debug information are sent to and from the emulator using this interface.
13.4.2.S On Chip Firmware Debugging (OCD) Advances in semiconductor technology has
brought out new dimensions to target firmware debugging. Today almost all processors/controllers in-
corporate built in debug modules called On Chip Debug (OCD) support. Though OCD adds silicon
complexity and cost factor, from a developer perspective it is a very good feature supporting fast and
efficient firmware debugging. The On Chip Debug facilities integrated to the processor/controller are
chip vendor dependent and most of them are proprietary technologies like Background Debug Mode
 Introduction to Embedded Systems

(BDM), OnCE, etc. Some vendors add 'on chip software debug support' through JTAG (Joint Test Ac-
tion Group) port. Processors/controllers with OCD support incorporate a dedicated debug module to the
existing architecture. Usually the on-chip debugger provides the means to set simple breakpoints, query
the internal state of the chip and single step through code. "OCD module implements dedicated registers
for controlling debugging. An On Chip Debugger can be enabled by setting tl}e OCD enable bit (The bit
name and register holding the bit varies across vendors). Debug related regi~ters are used for debugger
control (Enable/disable ·single stepping, Freeze execution; etc.) and breakpoint address setting. BDM
and JTAG are the two commonly used interfaces to communicate between the Debug application run-
ning on Development PC and OCD module of targer CPU. Some interface logic in the form of hardware
will be implemented between the CPU OCD interface and the host P<t to capture the debug information
from the target CPU and sending it to the debugger application running on the host PC. The interface
between the hardware and PC may be Serial/Parallel/USB. The following section will give you a brief
introduction about Background Debug Mode (BDM) and JTAG interface used in On Chip Debugging.
Background Debug Mode (BDM) interface.is a proprietary On Chip Debug soiution from Motorola.
BDM defines the communication interface between the chip resident debug core and host PC where the
BDM compatible remote debugger is running. BDM makes use of 10 or 26 pin connector to connect
to the target board. Serial data in (DSI), Serial data out (DSO) and Serial clock (DSCLK) are the three
major signal lines used in BDM. DSI sends debug commands serially to the target processor from the
r.emote debugger application and DSO sends the debug response to the debugger from the processor.
Synchroni~ation of serial transmissio!l is done by the serial clock DSCLK generated by the debugger .,
app,lication. Debugging is controlled by BDM specific debug commands. The debug commands are usu-:
ally 17-bit wide. 16 bits are used for representing the comm~nd and 1 bit for status/control.
Chips with JTAG debug interface contain a built-in JTAG port for communicating with the remote
debugger application. JTAG is the acronymfor Join,_TestAction Group. JTAG is the alternate nat.,fe for
IEEE 1149.1 standard. Like BDM, JTAG is also a serla1 interface:-The signal lines ofJTAG protqcol are
explained below.
Test Data In (TDI): It is used for sending debug commands serially from remote debugger to the target
processor.
Test Data Out (TDO): Transmit debug response to the remote debugger from tar9@{ CPU.
Test Clock (TCK): Synchronises the serial data transfer.
Test Mode Select (TMS): Sets the mode of testing.
Test Reset (TRST): It is an optional signal line used for resetting the t:arget CPU.
The serial data transfe~ rate for JTAG debugging is chip depend,erit. It is usually within the range of
10 to 1000 MHz. ·- ·

Even though the firmware is bug free and everything is iDitact in the board, your embedded product
need not function as per the expected behaviour in the first :;1ttempt for various hardware related reasons
like dry soldering of components, missing connections in the PCB due to any un-noticed errors in the
PCB layout design, misplaced components, signal corruption due to noise, etc. The only way to sbrt out
these issues and figure out the real problem creator is debugging the target board. Hardware debugging
is not similar to firmware debugging. Hardware debugging involves the monitoring of various signals
\
1
1 The Embedded System Development Environment
i

of the target board (address/data lines, port pins, etc.), checking the inter. connection among various
components, circuit continuity checking, etc. The various hardware debugging tools used in Embedded
1 Product Development are explained below.
i
13.5.1 Magnifying Glass (Lens)
l . You might have noticed watch r~pairer wearing a small magnifying glass while engaged·in repairing a
watch. They use the magnifying glass to view the minute components inside the watch in an enlarged
manner so that they can easily work with them. Similar to a watch repairer, magnifying glass is the pri-
mary hardware debugging tool for an embedded hardware debugging professional. A magnifying glass
is a powerful visual inspection tool. With a magnifying glass (lens), the surface of the target board can
be examined thoroughly for dry soldering of components, missing components, improper placement of
components, improper.soldering, track (PCB connection) damage, short of tracks, etc. Nowadays high
quality magnifying stations are available for visual inspection. The magnifying station incorporates
magnifying glasses attached to a stand with CFL tubes for providing proper illumination for inspection.
The station usually incorporates multiple magnifying lenses. The main lens acts as a visual inspection
tool for the entire hardware board whereas the other small lens within the station is used for magnifying
a relatively small area of the board which requires thorough inspection.

13.5.2 Multimeter
I believe the name of the instrument itself is sufficient to give· an outline of its usage. A multimeter is
used for measuring various electrical quantities like voltage (Both AC and DC), current (DC as well as
AC), resistance, capacitance, continuity checking, transistor checking, cathode and anode identification
- of diode, etc. Any multimeter will work over a specific range for each measurement. A multimeter is the
most valuable tool in the toolkit of an-embedded hardware developer. It is the primary debugging tool
for physical contact based hardware debugging and almost all developers start debugging the hardware
with it. In embedded hardware debugging it is mainly used for checking the circuit continuity between
different points on the board, measuring the supply voltage, checking the signal value, polarity, etc.
Both analog and digital versions of a multimeter are available. The digital version is preferred over
analog the one for various reasons like readability, accuracy, etc. Fluke, Rishab, Philips,. etc. are the
manufacturers of commonly available high quality digital multimeters.

'
1
l
l·,
'I
1
13.5.3 Digital CRO
Cathode Ray Oscilloscope (CRO) is a little more sophisticated tool co~ared to a multimeter. You might
have studied the operation and use of a CRO in your basic ele9tr--0mcs lab. Just to refresh your brain,
l
.J
I
CRO is used for waveform capturing and analysis, measurenfent of signal strength, etc. By connecting
1 the point under observation on the target board ts>, the Channels of the Oscilloscope, the waveforms can
l be captured and analysed for expected behaviour. CRO is a very good tool in analysing interference
noise in the power supply line and other signal lines. Monitoring the crystal oscillator signal from the
target board is a typical example of the usage of CRO for waveform capturing and analysis in target
board debugging. CROs are available in both analog and digital versions. Though Digital CROs are
costly, foaturewise they are best suited for target board debugging applications. Digital CROs are avail-
able for high frequency-support and they also incorporate modern techniques for recording waveform
over a period of time, c~pturing waves on the basis of a configurable event (trigger) from the target board
 Introduction to Embedded Systems

(e.g. High to low transition of a port pin of the target processor). Most of the modern digital CROs con-
tain more than one channel and it is easy to capture and analyse various signals from the target board cc
using multiple channels simultaneously. Various measurements like phase, amplitude, etc. is also pos- Tl
sible with CROs. Tektronix, Agilent, Philips, etc. are the manufacturers of high precision good quality
digital CROs.

13. 5. 4 Logic Analyser

A logic analyser is the big brother of digital CRO. Logic analyser is used for capturing digital data (logic
1 and 0) from a digital circuitry whereas CRO is employed in capturing all kinds of waves including
logic signals. Another major limitation of CRO is that the total number of logic signals/waveforms that
can be ·captured with a CRO is limited to the number of channels. A logic analyser contains special con-
nectors and clips which can be attached to the target board for capturing digital data. In target board de-
bugging applications, a logic analyser captures the states of various port pins, address bus and data bus I
of the target processor/controller, etc. Logic analysers give an exact reflection of what happens when I
a: particular line of firmware is running. This is achieved by capturing the address line logic and data j
line logic of target hardware. Most modern logic analysers contain provisions for storing captured datfl, ·I
selecting a desired region of the captured waveform, zooming selected region of the captured waveform,
etc. Tektronix, Agilent, etc. are the giants in the logic analyser market.

13.5.5 Function Generator

Function generator is not a debugging tool. It is an input signal simulator tool. A function generator is
capable of producing various periodic waveforms like sine wave, square wave, saw-tooth wave, etc.
~
with different frequencies and amplitude. Sometimes the target board may require some kind of periodic \'.2l
waveform with a particular frequency as input to some part of the board. Thus, in a debugging environ-
ment, the function generator serves the purpose of generating and supplying required signals.
sea
is k
'ou
. As the complexity of the hardware increase, the number of chips present in the board and the intercon- tot
. nection .among them may also increase. The device packages used in the PCB become miniature to and
reduce the total board space occupied by them and multiple layers may be required to route the inter- wit:
connections among the chips. With miniature device packages and multiple layers for the PCB it will be The
ID01
very difficult to debug the hardware using magnifying glass, multimeter, etc. to check the interconnec-
tion among the various chips. Boundary scan is a technique used for testing the interconnection among ary
the various chips, which support JTAG interface, present in the board. Chips which support boundaiy cell
scan associate a boundary scan cell with each pin of the device. A JTAG port which contains the five ·1
i inte
signal lines namely TDI, TDO, TCK, TRST and TMS form the Test Access Port (TAP) for a JTAG sup- pas:
ported chip. Each device will have its own TAP. The PCB also contains a TAP for connecting the JTAG
signal lines to the external world. A boundary scan path is formed inside the board by interconnecting
j OU~
<lat£
the devices throughJTAG signal lines. The TDI pin of the TAP of the PCB is connected to the TDI pin of
the first device. The TDO pin of the first device is connected to the TDI pin of the second device. In this li
mg
ope:
scar
way all devices are interconnected and the TDO pin of the last JTAG device is connected to the TDO lj
pin of the TAP of the PCB. The clock line TCK and the Test Mode Select (TMS) line of the devices are ~iv
l dire
.J
ary;
l
~
\
i
i The Embedded System Development Environment

i connected to the clock line and Test mode select line of the Test Access Port of the PCB respectively.
1 This forms a boundary scan path. Figure 13.41 illustrates the same. ·
l
il
Boundary Scan Cells Boundary Scan Path

PCB
TCK

As mentioned earlier, each pin of the device associates a boundary scan cell with it. The boundary
scan cell is· a multipurpose memory cell. The boundary scan cell associated with the input pins of an IC
is known as 'input cells' and the boundary scan cells associated with the output pins of an IC is known as
'output cells'. The boundary scan cells can be used for capturing the input pin signal state and passing it
to the internal circuitry, capturing the signals from the internal circuitry and passing it to the output pin,
ij and shifting the data received from the Test Data In pin of the TAP. The boundary scan cells associated
1. with the pins are interconnected and they form a chain from the TDI pin of the device to its TDO pin.
1 The boundary scan cells can be operated in Normal, Capture, Update and Shift modes. In the Normal
I mode, the input of the boundary scan cell appears directly at.its output. In the Capture mode, the bound-
1 ary scan cell associated with each input pin of the chip captures the signal from the respective 'p,ns to the
\ cell and the boundary scan cell associated with each output pin of the chip captures the si~nal from the
~ internal circuitry. In the Update mode, the boundary scan cell associated with each input pin of the chip
1 passes the already captured data to the internal circuitry and the boundary scan cell associated with each
1 output pin of the chip passes the already captured data to the respective output pin. In the shift mode,
aly data is shifted from TDI pin to TDO pin of the device through the boundary scan cells. I Cs support-
ing boundary scan contain additional boundary scan related registers for facilitating the boundary scan
operation. Instruction Register, Bypass Register, Identification Register, etc. are examples of boundary
1
:.
scan related registers. The Instruction Register is used for holding and processing the instruction re:
I · ~ived over the TAP. The bypass register is used for bypassing the boundary scan path of the device and

Ii
directly interconnecting the.TD! pin of the device to itsTDO. lt di~connects a device from the bound-
ary scan path. Different instructions are used for testing the 1hferconnections and the functioning of the
• I
 Introduction to Embedded Systems

chip. Extesr, Bypass, Sample and Preload, lntesf, etc. are examples for instructions for different types
of boundary scan tests, whereas the instruction Runbist is used for performing a self test tm the internal
functioning of the chip. The Runbist instruction produces a pass/fail result.
Bounda,y Scan Description Language (BSDL) is used for implementing boundary scan tests us-
ing JTAG. BSDL is a subset of VHDL and it describes the JTAG implementation in a device. BSDL
provides infom1ation on how boundary scan is implemented in an integrated chip. The BSDL file (File
which describes the boundary scan implementation for a device in .bsd format) for a JTAG compli-
ant device is supplied the device manufacturers or it can be downloaded from internet repository. The
BSDL file is used as the input to a Boundary Scan Tool for generating boundary scan test cases for a
PCB. Automated tools are available for boundary scan test implementation from multiple vendors. The
ScanExpressTM Boundary Scan (JTAG) product from Corelis Inc. (www.corelis.com) is a popular tool
for boundary scan test implementation.

Summary
. -✓ .Integrated Develop,.nen} Envfrqnmert (IDE) is an integrated envitonment for dey~Joping apd cleb'iig'~r',:;~
·target pro~esSor spe~ihc embedded firmware. IDE is a softwar~ pa~kage Which bu:ndles:.a 'rixtif!~it ...
Code Editor)', 'Crdss~compiler(for cross platform developmentand c9mpilerfor;s.arn~ptatfotln,)div(l
'Linker' and a 'Debygger,' · . ·•·.. .. ·. · . i; ',· } ... :: ·{ . . \ . . . .
. ✓ Keil µVision3 is~ licensed IDE to9l from Keil Software:{wv;r#,kei(cort1),.a1tAJ™ ~on;tp~ny,'fo,r,,;~
, . . ,, . .
mforocontroller based embeddegfirrµware development.··•··
·.': ·. .
,.,.,,i ·•·,: '-~ · · · • ·.· .·...·. · . · · ·• ·:: '
~ ~~. y:•·.J,. , "•_. -·-.-_-At ;,
.·_., _,.1 • · - .• , :' .;

✓ List File (1st), Pre-processor Outputfile, Maft ftt,~.(F~Ii~~~t~f!~i9Rt , ·,,;/·§~4~~!);1;gf/~6:lf(

(.hex). etc. are the files generated during the cross-compilatio1fpfo . a.soufcelil~:: ''· ., ·
· ✓ Hex fileifthe binary executable file created from the ·source co.de. Thi ;1:isoiute 9b]~ct fi\t1. ·
·locaterisconvert~d into processor understandablebinarycoae: Objecttd'Hex.fileconvert~tis·
.. for conx,ertingariobject file to a hex.file ... . . .
✓ Intel HEXru;tdMotorolaHEXare·lhe two·commonly used Hex file.fortnats"in·embedded ~pp\i~~tipgs\1,ll;,}'.
✓ Disassembler is a utility program which converts.machine codes into target.processor specific Assem:bly:chdes
instructions. Disassembling is the process of converting machine codes iµto Assembly code
✓ Decompiler is the utility program for translating machine codes into corresponding high level lhn.gq~g~ •.
instructions ,~ .,,,,\,,

✓ Simulator is a software application that precisely duplicates (mimics) the target CPU and simul<1tes the. variqµ;'s .
features and instructions supported by the target CPU · . . :,' ·
✓ Emulator is a self~contained hardware device whicli emulates the target CPU. Emulator hardware. 9oi;ifuiri~•
necessary emulation logic and it is hooked to the debugging application running on the development P(: qn'ql'l~,
end and connects to the target board through some interface on the other end · · · ··
✓ Incremental EEPROM Burning technique, Inline breakpoint based Finnware Debugging, Mdnitbf Ptqgtarp,
based Firmware Debugging, In Circuit Emulator (ICE) based Firmware Debugging and On Chip "Firin.wafe
Debugging (OCD) are the techniques used for debugging embedded firmware on the target hardware . : . .. ·
✓ Background Debµg Mode (BDM) Interface and JTAG are the two commonly used interf~ces for;0h @tifo,
FinnwareI;)ebugging(OCD) . ,. · .. ··: ,·.;Jf:
✓ Magni:fyink glass, Muiti~eter, Cathode Ray Oscilloscope (CRO), Logic Analyser and Function gener!}.tq~;ar~lli~,
commonly used,har1war~ debu~gmg :ools . . . . _ . . · · . ;\ :1 r 'E~~.,;
✓ ·Boundary scan is a technique for testmg the mterconnect:ton among the vanous chips, which supportboµn\:lazyi,
scanning~ in a complex board containing too many interconnections and multiple planes for routing .· · ··, · ·
✓ Boundary Scan Description Language (BSDL) is a language similar to VHDL, which describes 'the' boundi;&:. .. ··>t,.,, •'
l
l

• .
;

i The Embedded System Development Environment

1i

\ scan implementation o(aJlevice and is used for implementing b9uf!d3:ry scan tests using JTAG. BSDittil~ig ·

li a file containing the boundary :scan descriptiori'for a device in boundary scan description language, '.whkl,t:is
supplied as input to aBqurtdary scan tool for generating the boundary scan test cases . . ..... .

Integrated l)eyelo~ipent
Environment(IDE{ ..
•
r~-K_e_yw-or_d_s____)

.: A sofuy~e:p~okage which bundles aynixt Ec!jtor (SQ~fS~(

. 'Crds~:tbufpHer<(for cross platfom1; "de~eWpmJiiffii~a '6,gJ:ti
platform dev,elopment)', 'Linker.' an.d a 'Pebµgger' ·· · .. . "''
··.=.-.,.. ',,;;;,_i,"\ :,., ·'',:.>,,,,,;•': ·:· . ,· /:\ ~1:j; ; .. Jit.;I";t:::~~t,,·:y:.";J.>,:;,,1\:,.•·•,\,,, -.,;·,q'.;);.t'i lTP,·=
0

kl:i µVisiori3 A .licensed

·:,.;:.·, (
I.DEt<)Ol from:Keil Softwarn ( .... ke· · ,;('
,:,,-',,} ~··:,},'_:~:;:.''. ·, -. \.) ' --~--'0:,.?:,\-,,-~-J>i-,: )/·,
), .an, ' ~..
/,;'•'::·\f<·-~
, .far 80~ 1 f~milymicro,contrqller
,,.· ~·t ' :,... i ·\,'. ;.i> .. , - '
b~ecl
-' ' .
eJl!petided
"':/ ,
ware de;i.tel.
,'.
·--,.c- ; , ,

. ,£ile generated}ll.irfog crpss c9mpii~tiqn,.'of ~ ..sQ:qrce c9de,.aJid'.i

inforrnatibtr;aboilt the cross co~pilatiq~ proc,~~s, i'~si crbss ;~~iih~t:
fonnatted. source text ('C' code); ass~~ply code generated frm1,1;the
file, symbol tables, errors and warnings 9~t~qted.qfu"ing:thecro~st ~,,
process, etc.
Object File:C.OBJ File) ·· : A specially formatted file with data records for symbolic inforn;rat{ ·
code, debugging information, library references, etc. generated 1dµf
cross-compilation of a source file .
Map file File generated during cross-compilation process and it contains ihfQ~a'
about the link/locate process. . .. )tJ{
Hex·file The binary executabl~ fl.Ii/created frop}hd source code
Intel$X HEX file representation format
. Motor9la'HEX HEX file. representation fonnat
Disassembler Utility program which converts machine codes into target pro1ceE:sor,;speci1tic
Assembly codes/instrnctions.
Decompiler Utility program for translating machine codes into corresponding hignleyel
language instructions · ' '
Simulator Software application that precisely duplicates (mimics) the target CPU and
simulates the various features and instructions supported by the target yPU
Monitor Program Program which acts as a supervisor and controls the downloadiµg of user
code into the code ·memoiy, inspects and modifies register/memory locations,
allows single stepping of source code, etc.
In Circuit Emulator (ICE) A hardware device for emulating the target CPU for debug purpose
Debug Board Module (DBM) ICE device which contains the emulationcontrol logic and emulation chip in
a single h~rdware unit and is designed for a particular family of device
Background Debug Mode (BDM) :' A prbprie(aiy serial interface from Motorola for On Chip Debugging
l '

JTAG A serial interface for target board diagnostics and debugging

Boundary Scan A target hardware debug method for checking the interconnections among
the various chips of a complex board ;
·. Boundary Scan Description A language similar to VHDL, which describes the boundary scan
Laqguage (BSDL) implementation of a JTAG supported device
, l
 Introduction to Embedded Systems

Objective Questions
I Which of the following intermediate file, generated during cross-compilation of an Embedded C file holds the
assembly code generated corresponding to the c source code. .
(a) List File (b) Preprocessor output file . (c) Object file (d) Map file
2 Which of the following detail(s) is(are) kept in an object file generated during the process of cross-compiling an
Embedded C file.
(a) Variable and function names (b) Variable _and function reference
(c) Reserved memory for global variables (d) All of these
(e) None of these
3 Which of the following intermediate file, generated during the cross-compilation of an Embedded C files holds the
information about the link/locate process for the. multiple object modules of the project? .
(a) List file (b) Preprocessor output file (c) Object file (d) Map file
4 Which of the following file generated during the cross-compilation process of an Embedded C project holds the
machine code corresponding to the target processor?
(a) List file (b) Preprocessor output file (c) Object file (d) Map file
5 Examine the following Intel HEX Record
:03000000020C1FD0
This record is ?
(a) a Data Record (b) an End of File Record (c) a Segment Address Record
(d) an Extended Linear Address record
6 Examine the following Intel HEX record
:03000000020C 1FD0
What is the number of data bytes in this record?
(a) 0 (b) 3 (c) 2 (d) 20
7 Examine the following Intel HEX record
':03000000020Cl FD0
What is the start address of the data bytes in this record?
(a) 0x0000 (b) 0x3000 (c) 0xlFD0 (d) 0x20Cl
8 Examine the following Intel HEX Record
:03000000020C 1FD0
Which all are the data bytes present in this record?
(a) 03, 00, 00 (b) 02, 0C, IF (c) 0C, IF, DO (d) 00, 00, 20
9 The program that converts machine codes into target processor specific Assembly code is known as
(a) Disassembler (b) Assembler (c) Cross-compiler (d) Decompiler
IO Which of the following is true•about a simulator used in embedded software debugging?
(a) It is a software tool (b) It requires target hardware for simulation
(c) It doesn't require target hardware for simulation (d) (a) and (b) (e) (a) and (c)
11 Which of the following is an example for on chip firtnware debugging?
(a) OnCE (b) BDM (c) .All of these

Review Questions

j
I

1 Explain the various elements of an embedded system development environment.

2 Explain the role of Integrated Developmenf'Eri~ironment (IDE) for Embedded Software Development.

l
 The Embedded System Development Environment

3 What are the different files generated during the cross-compilation of an Embedded C file? Explain them in
detail.
4 Explain the various details held by a List file generated during the process of cross-compiling an Embedded C
project.
5 Explain the various details held by a Map file generated during the process of cross-compiling an Embedded C
project.
6 Explain the various details stored in an Object file generated during the cros~-compilation of an Embedded C file.
7 Explain the difference between Intel Hex and Motorola Hex file fonnat.
8 Explain the fonnat of Hex records in an Intel Hex File.
9 Explain the fonnat of Hex records in a Motorola Hex File.
10 What is the difference between an assembler and a disassembler? State their use in Embedded Application
development.
11 What is a decompiler?
12 What is the difference between a simulator and an emulator?
13 Explain the advantages and limitations of simulator based debugging.
14 What are the different techniques available for embedded finnware debugging? Explain them in detail.
15 What is a Monitor program? Explain its role in embedded firmware debugging?
16 What is ROM emulation? Explain In Circuit Emulator (ICE) based debugging in detail.
17 Explain On Chip Debugging (OCD).
18 Explain the different tools used for hardware debugging.
19 Explain the Boundary Scan based hardware debugging in detail.

•:swi
A Impl
"5 1 Wrlf

..... , '.,

· · :... ,t, opc)lr

·. •·,..,;·Ff~erial::P;,
·;:~':'Implelll~.U · ~a o
Introduction to Embedded Systems

l
l
The saying "The first Impression is the last impression" is really meaningful in the commercial embed-
ded product market. No matter whatever features a commercial product offers compared to its com-
petitor's product, the aesthetics of the product plays an important role on its demand and popularity. A
mobile handset is a typical example for this. Most of the end users prefer handy, compact, rugged hand-
sets with user friendly keypads among a set of handsets by various manufacturers offering more or less
the same features. For a successful commercial embedded product, the features offered and product
aesthetics must be well balanced. Product aesthetics refers to the look 'n' feel, size, weight and shape of
the product. User friendliness (Navigation key order, placement, accessibility, etc.) is another important
factor that should be considered for products inv<:>lving extensive user interactions. In most of the product
development process, the engineering design of the product is canied out by a mechanical engineering
wing. The mechanical engineering team and embedded hardware development team should work hands
on hand to develop products with nice aesthetics. The mechanical _design team is responsible for design-
ing the product enclosure and this design is executed in parallel with the design of embedded hardware
and firmware. However, the aesthetics of the product should be finalized before the development of
the real embedded hardware (PCB). The PCB size and shape are restricted by the suggested product
enclosure. The PCB should be routed in a way to incorporate the directions (like placement of keyboard
 Introduction to Embedded Systems

if any, display unit if any, PCB mounting holes, placement of connectors, etc.) from the engineering
design team. Apart from the product aesthetics, the engineering design team should be well aware of the
budget limitations for the product and they should be capable of suggesting a design fitting into the al-
located budget. Some technical aspects also need to be considered while selecting materials for product
enclosures. For example, certain products involving RF signals cannot use metal enclosures since they
absorb the RF signals and reduce the field strength, hence in such cases some cheap alternatives should
be put forward. The enclosure design should also take into account various protections like mechanical
shock, water resistance, etc.

Frankly speaking, product enclosure design is an art. As a sculpture shows the artistic ability of its l
creator, the product's enclosure reflects the design capabilities of its designer. With the latest design
technologies, the custom drawing using pen and pencil on paper for a design (front, top and end view
of the design) has given way to Computer Aided Design (CAD). A variety of CAD tools are available
for Product Enclosure Design. 'Solidworks', 'AutoCAD\ 'ProEngineer', 'Catia Interface', etc. are ex-
amples of CAD tools. By combining the artistic ability of the designer with the design flexibility offered
I
by the automated tools, good product enclosures maintaining very good aesthetics can be developed.
I
Choosing the right enckisure (housing) for a design is dependent upon a variety of product specifica-
I
tions like size, shielding, materials and construction, ergonomics, customisability, operating conditions
and protection.requirements. Various techniques and materials are used for the enclosure (housing) de-
velopment of the product. The commonly used materials for enclosure (housing) development are metal
and variants of plastic. The de facto standard for plastic is ABS (acrylonitrile-butadiene-styrene). ABS is
used in a multitude of consumer products ranging from children's toys to mobile handsets. Metal is been
pushed down in most modem products for the requirement lightweight and compactness. Plastic is the.
right choice for products demanding lightweight and compactness whereas metal is the right candidate
,for products requiring ruggedness and extensive shielding from external RF interference. Certain ap-
plications demand products with tight sealing and watertight enclosures conforming to protection stan-
dards like IP 65, NEMA 4, etc. The following sections give an overview of various techniques adopted .I
in Product enclosure (housing) development.
1
14.2.1 Handmade Enclosures
This is the best choice for enclosure development for prototype products and low volume product re-
quirements. The capital investment required is very small for handmade enclosures. Commonly used
materials for handmade enclosures are plastics like Poly Vinyl Chloride (PVC) and Acrylic. The PVC/
Acrylic sheet can be cut into desired shape and combined using a suitable adhesive. It is a low cost tech-
nology but limited to the fabrication oflow volume products. The manpower involved is comparatively
high and development time is also high.

14.2.2 Rapid Prototyping Development

Rapid prototyping is a 3-Dimensional Computer Assisted Manufacturing (3D CAM) technique used for
prototype development as well as mass production. The 3D model designed using any of the 3D CAD
 Product Enclosure Design and Development

tools is used as input for this. Rapid .prQtotyping is also known as generative manufacturing or solid
freefonn fabrication or layered manufacturing. Rapid prototyping is best suggested for Proof of Concept
(PoC) models. The various techniques adopted in rapid prototyping are listed below.
14.2.2.1 Stereolithography (SLA) Prototyping Stereo lithography is considered as the first rapid
prototyping technology and it was developed by 3D systems of Valencia, CA, USA. It is commercially
introduced in the year 1988. Stereolithography is a process in which liquid plastic is solidified in precise
patterns by a UV laser beam, resulting in a solid epoxy realisation of a 3D design of the enclosure. SLA
a
prototyping machine uses computer to direct UV laser to solidify photosensitive polymer layer upon
layer to produce a physical object. On completion of each layer, the surface is re-wetted and the laser
hardens the next layer. Upon.completion of the entire layer, the part is cleaned and cured. This technique
is also referred as 3D layering or 3D printing.
14.2.2.2 Selective Laser Sintering (SLS) Prototyping Selective Laser Sintering (SLS) is simi-
lar to SLA, except that the 3D prototypes are created from the drawing by fusing or sintering powdered
thennoplastic materials layer by layer. SLS system consists of a part chamber, laser unit and a comput- .
erised controller. The part chamber contains a building platfonn, powder cartridge and levelling roller.
The powder cartridge sinters the material over the building platfonn. The advantage of SLS over SLA
is the range of materials available; including nylon, metals, and elastomers.
14.2.2.3 Fused Deposition Modelling (FDM) Fused Deposition Modelling (FDM) is a solid-
based rapid prototyping method. It makes use of melted thermoplastic polymer in the fonn of paste for
building the layers. The·FDM system consists of a build platfonn, extrusion nozzle, and control system.
In order to generate a two-dimensional cross section of the model under consideration, production qual-
ity thermoplastics (largely ABS} is melted and then extruded through a specially designed head onto a
platform. The platfonn is lowered down once the newly extruded layer is solidified, for extruding the
next layer. This process is repeated until the model is complete. On completion the model is taken out
of the build platfonn .chamber and cleaned properly.

14. 2 .3 Tooling and Moulding

The tooling and moulding techniques are mainly used for developing plastic and metal housings for
high volume production. ABS, nylon, polycarbonate, acrylic and a variety of other polymers are the
commonly used plastic. The initial investment for_making a tool or mould is too high and hence it is
profitable only for high volume productions. Once a tool or mould is developed, thousands of pieces can
be developed from it and this will convert the initial investment into per piece housing price. The widely
adopted tooling and moulding techniques are:
14.2.3.1 Room Temperature Vulcanised (RTV) Tooling Room Temperature Vulcanised (RTV)
tooling technique is used for polyurethane housings. First an RTV rubber tools is created by pouring
liquid silicone rubber around a master pattern. The resulting model is taken: out of the mastet pattern,
finished well and then used for casting polyurethane housings. These housings are painted according to
the user needs. Text and graphics can be printed on top of the painted housing. The key ,advantage of
RTV is the ability to produce high volume prototypes at a nominal cost. ··'
14.2.3.2 Computer Numeric Control (CNC) Tooling In Computer Numeric Control (CNC)
tooling, CNC machines are used for milling the block of plastic according to the input from a des13:"' file
generated by the 3D modelling tool to develop desired liousing.·

\
 Introduction to Embedded Systems

14.2.3.3 Injection Moulding Injection moulding system consists of a moulding machine and
mould plates (dummy shape of the product to be developed). Plastic/resin is fed into the injection barrel
of the machine through the hopper and in the barrel it is heated to the appropriate melting temperature.
Molted resin is injected to the space between the mould plates through a nozzle to create moulds. Mould
is cooled constantly to a temperature that allows the resin to solidify. Mould plates fl,re held together by
· hydraulic or mechanical force.

14.2.4 Sheet Metal Work

Sheet metal is the foil (thin) form of metal sheets, which can be cut or bend into different shapes. Cop-
per, brass, mild steel, aluminum, tin, nickel, titanium, etc. are examples for metals used in sheet metal
work. The thickness of metal sheets used for sheet metal work normally falls below 6 mm. Sheet metal
is the best choice for product enclosures where aesthetics are not a big constraint, where a functional
product is the only requirement. Sheet metal is best suited for products demanding high ruggedness.
Sheet metal is not a good choice for products including any RF circuitry, since the enclosure tend to at-
tenuate the RF field. Also fancy works like contours, curves are not possible to build on housing using
sheet metal work.

14.2.5 Commercial Off-the-Shelf Enclosures (COE)

Commercial off-the-shelf enclosures are the readily available enclosures in the market. It can be either
plastic or metal. They are generally available with rectangular, square and circular shapes and with vari-
ous dimensions. Multimeter housings, plastic boxes, etc. are typical examples for COE. If the product
is important only in terms of functionalities and not in tenru; of aesthetics, you can go for a commercial
off-the-shelf enclosure. Before building the hardware, identify the best-suiting COE and tailor the PCB
I
to fit into the selected COE. COE is best suited for concept development projects and product develop-
ment work with low budget.

14.3 SVMMARY
Competitive products where features as well as aesthetics are important should always require attractive
enclosures. Mobile handsets, children toys, etc. are example·s of it. The more you make the enclosure
attractive, the more is the demand. Custom enclosure development is required for such products. Proof
of Concept (PoC) design products and products which are not aiming a commercial market can go for
either custom enclosure or Commercial off-the-shelf enclosure. Moreover the enclosure should consider
any special needs by the product like protection standards, shielding requirements, etc.

✓
' • ,,,, \
Summary
a

Product enclosure [s essential fqr p~otectin_g the hardware from dust, water, corrosion, etc. to provide ruggedness
l
J
and to provide a good aesthetics (look and feel) to the product .
✓ :eroduct enclosure.design..should take care ofthe aesthetic~', protebtion requirements, shielding requirements, etc.
✓ Product enclosure design deals with the design-of the enclosure for the embedd~d product (Hardware with
firmware integrated). Various computer aided design(CAD) tools like 'Solidworks', 'AutoCAD', 'ProEngineer',
'Catia Interface', etc. can be used for product enclosure design
 Product Enclosure Design and Development

✓ Prodt1ct enclosur~ .can be de)ieloped manually or using C()mputer Assisted Manufacturing (CAM) tools bas,e9 on
1f
t)ledesign file .ge~~ratedftplll .i· Co;i;rp4ter Aided I;)esign · ·
✓ ·1®14:µ:i~ge enc.lps,µre'.'"J.s,.a;typJf~t;.e,)f~Q.lPle formanµ~lly developed;prnduct enclosur~. Itfa the best choJti:'fqf .·
. ·· · . ·. . .. . . . · ...· · ·. \ r·
protoWJ)e and19W:;v~li:nf1pj;p4P:c;fton.•It
;-\- •',••,:.',_ r---~" or
;,;•, ...,; '_'.;::,;o·~;_·:·.:t<<'.\\'<:,,'..,-:-':\¼>/~"'•···- ;,, '."uses.• plastics' 'like AB$. PVC an,d sheet,metaffor enclosilre d~~t@'~t~\;
c;; __ -- _ ' .,,_• , ->>.•-\{~J'(::_f~:~·
✓ Rapi.dprot9J:yPin isa 3~~i-m:ylltl()11a! Computer i\ssisted M~11fa.ctu;i1tg (3D CMi) tec~ic.n!5}1J.Sedfo.r prnt<mi~{
}?f~~?~.lli~pr/,. .. ~91t, .... ,........ ,, ;.,.,i.,.·.:.L. -.... ·. , :'~· ·<·'' .•· ...• • ;~~;;/:~:
· ✓ ·Stere~htho~apll < . . . . . ser Sll}te1;mg (SLS), Fµsea Qepos,1t1on Modelling {FDM):,·etc:are ex~ti;ipLti:r:,
fo~ iar"ioyi ' \Jf ra;ia;pi g . . .· .. .. ' . . . . .· .· ... ·.• . . < . . "
✓ Stere6litlio, , Jt~l!qui<l Pl~s~c'is soli~ified in precise patterns oya UV laser b~aU1/re~
in,il&b1jdepox,z,, <;ij~sigµ ofgi~e~,cl~~ure: ,, ' . •·· . . . , ·...•. ,. <' ·? ~-;."
✓ . Seli~t}y~f~~~r ~. ,~mi\~rt<fS~A/ixfeP,ilh~ttne}D prototypes are creat~d fforµthe dra\1/iii~J,tr
fusiqg\gr:smt~ritig, plastic m~terials layerby':layer . .. ' "'} 1;'/If1Jt~ft
✓ Fu;edDepositi611( ... ·. ,··•.·...•. ·.·•·. Jfsa'solid~basedr~pWprototypingmethod, wliich,p.ses 111ehed thermop . ,, .. ,.
polyrnerfothe.fotnt§fgi£f~'.,fi, , ., ];lildiIJgt~~aayers• •· ·' : ·· · · . · . · ;1>iI:'i<·•J:: >,'i;,;:;~tt~ <: }.
✓ Thetoqlit:1g and ni~~ld.m'i{t~~hhi~ues are mainly used for de'veloplllg plastic and mefal:li?usingsfor high.:v.pl1!hl'.f 1
production. Her~Ji tooLor niciuld is developed first and the enclosure is developed ;from this mould. R&bfo.
Temperature Vulcanised (R.T\T),C9mputer Numeric Control (CNC), injection moulding, etc. ~re e,c:ampl~s for ..
tooling techniques ·. ·. . . ;, .it
✓ Room TempetatureVi.ilcan1$e~fpt:t'Y) to~ling !~duiique l~ &~~~for,_ p6l~ethane hoµsing~: F_irst an RTVni,~§~r
tool is <;reated by.p9uring·1lqµiq>silicone rubber around a master pattern. The resulti11g~9dehs tak~n out qf Jlie.
master pa:tt~mffinish~d'.w~Harttl!.hen used,for casting polyurethane housings · . , , ·.· '
✓ In ComputerNuriJeric ~onfrol(CNq tooling, CNGmachines a~e used for milling the bloclcofplasticaccqrding
to the input fronrn designfilegeriera.ted bfthe 3b modeling too'l to develop desireo h~u,si~f . · . . . . ,.' , ..·
✓ Injection moulding system:con~ists 6fa moulding machine andmould plates tdummy shap'(?of the ,prbdutfto;be
developed). Plastic/resin is fed irito the ,injection barrel of the machine through the hopper arid in the barrel it
is heated to the appropriate meltfugtemperature. Molted resin is injected to the space betw.een the.mould plates
through a nozzle to create moulds . . .
✓ Sheet metal is the foil (thin) form of metal sheets, which can be cut or bent into different s,hapes
✓ Commercial off-the-shelf enclosure is the readily available enclosures in the market. It can be either plastic·or
metal

Product Enclosure A protective casing for the hardware product

Acrylonitrile-Butadiene-Styrene A type of plastic used in product enclosure development
(ABS)
Handmade Enclosure Manually developed enclosure using plastic or sheet metal
Computer Assisted Design Design using software tools
(CAD)
Computer Aided Manufacturing Manufacturing process with the aid of software tools
Rapid Prototyping A 3-Dimensional Computer Assisted Manufacturing (3D CAM) technique
for prototype development as well as mass production
Stereolithography (SLA) A rapid prototyping technique in which liquid plastic is solidified in precise
patterns by a UV laser beam, resulting in a solid epoxy realisation of a 3D
design of the enclosure
 Introduction to Embedded Systems

J
j

lI
I
Objective Questions
1 Which of the following is not a Rapid Prototyping technology for product enclosure development?
(a) Selective Laser Sintering (SLS) (b) Fused Deposition Modelling (FDM)
(c) Room Temperature Vulcanisation (RTV) (d) -Stereolithography (SLA)
2 Which of the following is not a Tooling and Moulding technology for product enclosure development?
(a) Room Temperature Vulcanisation (RTV)' (b) Sheet metal
(c) Injection moulding (d) CNC tooling

Review Questions
Explain the various factors that need to be addressed while selecting an enclosure for an embedded product.
2 Explain the different product enclosure development techniques in detail
3 What are the merits and limitations of Handmade Enclosures?
4 What is Rapid Prototyping? What are the different techniques available for Rapid Prototyping? Explain the merits
and limitations of each.
5 Explain the Tooling and Moulding techniques used for product enclosure development
6 Explain the Sheet Metal based product enclosure development
·:~~tfu1:1f~t. ,.,-,. .
,,:;"'.''''>•
· . ;development'.lffe cycle,
·W
dnagitnierit ·, . .·
✓ ·Learn •abi:wtthe applicapon, cidvantages and limitations of Spiral Model iiLembedded product development life
cyde.mdnageinent . .. . . .

Just imagine about your favourite chicken dish that your mom served during a holiday lunch. Have
you ever thought of the effort behind preparing the delicious chicken dish? Frankly speaking No, Isn't
it? Okay let's go back and analyse how the yummy chicken in the chicken stall became the delicious
chicken dish served on the dining table. One fine morning Mom thinks "Wohh! ! It's Sunday and why
can't we have a special lunch with our favourite chicken dish." Mom tells this to Papa and he agrees on
it and together they decide how inuch quantity of chicken is required for the four-member family (may
be based on past experieqce) and lists out the various ingredients required for preparing the dish. Now
the list is ready and papa checks his purse to ensure whether the item list is at the reach of the money in
his purse. If not, both of them sit,together and make some reductions in the list. Papa goes to the market
 Introduction to Embedded Systems

to buy the items in the list. Finds out a chicken stall where quality chicken is selling at a nominal rate.
Procures all the items and returns back home with all the items in the list and hands over the packet to
Mom. Mom starts cleaning the chicken pieces and chopping the ingredient/vegetables and then puts
them in a vessel and starts boiling them. Mom may go on to preparing other side dishes or rice and
comes back to the chicken dish preparation at regular intervals to add the necessary ingredients (like
chicken masala, chilly powder, coriander powder, tamarind, coconut oil, salt, etc.) in time and checks
· whether all ingredients are in c.orrect proportion, if not adjust them to the required proportion. Papa
gives an overall supervision to the preparation and informs mom if she forgot to add any ingredients
and also helps her in verifying the proportion of the ingredients. Finally the fragrance of spicy boiled
chicken comes out of the vessel and mom realises that chicken dish is ready. She takes it out from the
stove and adds the final taste building ingredients. Mom tastes a small piece from the dish and ensures
that it meets the regular quality. Now the dish is ready to serve. Mom takes the responsibility of serving
the same to you and what you need to do is taste it and tell her how tasty it is. If you closely observe
these steps with an embedded productdeveloper's mind, you can find out that this simple chicken dish
preparation contains various complex activities like overall management, development, testing and re-
leasing. Papa is the person who did the entire management activity starting from item procurement to
giving overall supervision. Mom is responsible for developing the dish, testing the dish to certain extent
and serving the dish (release management) and finally you are the one who did the actual field test. All
embedded products will have a design and development life cycle·similar to our chicken dish prepara-
tion example, with management, design, development, test and release activities.

Embedded Product Development Life Cycle (Let us call it as EDLC, though it is not a standard and
universal term) is an 'Analysis-Design-Implementation' based standard problem solving approach for
Embedded Product Development. In ariy product development application, the first and foremost step is
-, '
to figure o:ut what product needs to be developed (analysis), next you need to figure out a good approach
for building it (design) and last but not least you need to develop it (implementation).

EDLC is essential for understanding the scope and complexity of the work involved in any embedded
product development. EDLC defines the interaction and activities among various groups of a product de-
velopment sector including project management, system design and development (hardware, firmware
and enclosure design and development), system testing, release management and quality assurance. The
standards imposed by EDLC on a product development makes the product, developer independent in
tenns of standard documents and it also provides uniformity in development approaches.

15.3 QBJEC1'ffES ·OF·EllLC

The ultimate aim of any embedded product in a commercial prqduction setup is to produce marginal
benefit. Marginal benefit is usually expressed in terms of Return on Investment (ROI). The investment ~.
for a product development includes initial investment, manpo;wer investment, infrastructure investment, -1~1-
etc. A product is said to be profitable only if the turnover from the.selling of the product is more than that ~

1I
1
l
l The Embedded Product Development Life Cycle (EDLC)
l
;

of the overall investment expenditure. For this, the product should be acceptable by the end user and it
should meet the requirements of end user in terms of quality, reliability and functionality. So it is very
' essential to ensure that the product is meeting all these criteria, throughout the design, development,

ll implementation and support phases. Embedded Product Development Life Cycle (EDLC) helps out in
ensuring all these requirements. EDLC has three primary objectives, namely
1. Ensure ·that high quality products are delivered to end user.
2. Riskminimisati.on and defect prevention in product development through project managem~nt.
3. Maximise the productivity.

15.3.1 Ensuring.High Quality for Products

The primary definition of quality in any embedded product development is the Return on Investment
(ROI) achieved by the product. The expenses incurred for developing the product may fall in any of
the categories; initial investment, developer recruiting, training, or any other infrastructure requirement
related. There will be some budgetary and cost allocation given to the development of the product and
it will be allocated by some higher officials based on the assumption that the product will produce a
good return or a return justifying the investment. The budget allocation might have done after study-
ing the market trends and requirements of the product, competition, etc. EDLC must ensure that the
development of the product has taken account of all the qualitative attributes of the embedded system.
The qualitative attributes are discussed separately in an earlier chapter of this book. Please refer back
for the same.

15.3.2 Risk Minimisation and Defect ·Prevention through Management

You may be thinking what_is_the significance of project management, or why project management is
essential in product development. Nevertheless it is an additional expenditure to the project! Ifwe look
back to the chicken dish example, we can find out that the management activity from dad is essential
in the beginning phase but in the preparation phase it can be handled by mom itself. There are projects
in embedded product development which requires 'loose' or 'tight' project management. If the product ,
development project is a simple one, a senior developer itself can take charge of the management activ-
ity and no need for a skilled project manager to look after this with dedicated effort throughout the de-
velopment process, but there should be an overall supervision from a skilled project management team
for ensuring that the development process is going in the right direction. Projects which are complex
and requires timeliness should have a dedicated and skilled project management part and hence they are
said to be "tightly" bounded to project management. 'Project management is essential for predictabil-
ity, co-ordination and risk minimisation'. Whenever a product development request comes, an estimate
on the duration of the development and deployment activity should be given to the end user/client.
The timeframe may be expressed in number of person days PDS (The effort in terms of single person
working for this much days) or 'X person for X week (e.g. 2 person 2 week) etc. This is one aspect of
predictability. The management team might have reached on this estimate based on past experience
in handling similar project or on the analysis of work summary or data available for a similar project,
which was logged in using an activity tool. Resource (Developer) allocation is another aspect of predict-
ability in management. Resource allocations like how many resources should work for this project for
how many days, how many resources are critical with respect to the work handling by them and how
many backups required for the resources to 9vercome a critical situation where a resource is not avail-
able (Risk minimisation). Resource alloc·ation is critical and it is having a direct impact on investment.
 Introduction to Embedded Systems

The communication aspect of the project management deals with co-ordination and interaction among
resources and client from which the request for the product development aroused. ·Project management
adds an extra cost on the budget but it is essential for ensuring the development process is going in the
right direction and the schedules of the development ·activity are meeting. Without management, the
development work may go beyond the stipulated time frame (schedule slipping) and may end up in a
product which is not meeting the requirements Jrom the client side, as a result re-works should be done
to rectify the possible deviations occurred and it will again put extra cost on the development. Project
l
'

management makes the proverb "A stitch in time saves nine" meaningful in an embedded product devel-
opment. Apart from resource allocation, project management also covers activities like task allocation,
scheduling, monitoring and project tracking. Computer Assisted Software Engineering (CASE) Tools
and Gantt charts help the manager in achieving this. Microsoft® Project Tool is a typical example of
CASE tool for project management.

15.3.3 Increased Productivity

Productivity is a measure of efficiency as well as Return on Investment (ROI). One aspect of productiv-
ity covers how many resources are utilised to build the product, how much investment required, how
much time is taken for developing the product, etc. For example, the productivity of a system is said
to be doubled if a product developed by a team of 'X' members in a period of 'X' days is developed
by another team1of 'Xl2' members in a period of 'X' days or by a team of 'X' members in a period of
'Xl2' days. This productivity measurement is based on total manpower efficiency. Productivity in terms
of Returns is said to be increased, if the product is capable of yielding maximum returns with reduced
investment. Saving manpower effort will definitely res.ult in increased productivity. Usage of automated
tools, wherever possible, is recommended for this. The initial investment on tools may be an additional
burden in terms of money, but it will definitely save effortsJn the next project also. It is a one-time
investment. "Pay once use many time". Another important factor which can help in increased produc-
tivity is ·"re-usable effort". Some of the works required for the current product development may have
some common features which you built for some· of the other product development in the projects you
executed before. Identify those efforts and design the new product in such a way that it can directly be
plugged into the new product without any additional effort. (For example, the current product you are
developing requires an RS-232C serial interface and one of the product you already developed have the
same feature. Adapt this part directly from the existing product in terms of the hardware and firmware
required for the same.) This will definitely increase the productivity by reducing the development effort.
Another advised method for increasing the productivity is by using resources with specific skill sets
which matches the exaft requirement of the entire·or part of the product (e.g. Resource with expertise
in Bluetooth technology for developing a Bluetooth interface for the product). This reduces the learning
time taken by a resource, who does not have prior expertise in the particular feature or domain. This is
not possible in all product development environments, since some of the resources with the desired skill
sets may be engaged with some other work and releasing them from the current work is not possible.
Recruiting people with desired skill sets for the current product development is another option; this is
worth only if you expect to have more work on the near future on the same technology or skill sets. Use
of Commercial Off-the-Shelf Components (COTS) wherever possible in a product is a very good way of
reducing the development effort and thereby increasing the productivity (Refer back to the topic 'Com-
mercial Off-the-shelf components' given in Chapter 2 for more details on COTS). COTS component is
a ready to use component and you can use the same as plug-in modules in your product. For example,
 The Embedded Product Development Life Cycle (EDLC)

if the product under development requires a 10 base T Ethernet conneytivity, you can either implement
the same in your product by using the TCP/IP chip and related·components or can use a readily available
TCP/IP full functional plug-in module. The second approach will save-effort and time. EDLC should
take all these aspects into consideration to provide maximum productivity.

The life cycle of a product development is commonly referred to as models. Model defines the various
phases involved in the life cycle. The number of phases involved in a model may vary according to the
complexity of the product under consideration. A typical simple product contains five minimal phases
namely: 'Requirement Analysis', 'Design', 'Development and Test', 'Deployment' and 'Maintenance'.
The classic Embedded Product Life Cycle Model contains the phases: 'Need', 'Conceptualisation',
'Analysis', ' Design', 'Development and Testing', 'Deployment', 'Support', 'Upgrades' and 'Retirement/
Disposal' (Fig. 15.1). In a real product development environment, thephases given in this model may
vary and can have submodels or the models contain only certain important phases of the classic model.
As mentioned earlier, the number of phases involved in the EDLC model depends on the complexity of
the product. The following section describes each phases of the classic EDLC model indetai[

Retirement Need Conceptualisation

Analysis

EDLC
Upgrades
Design

Development and
Support Testing
Deployment

15.4.l Need
Any embedded product evolves as an output of a 'Need'. The need may come from an individual or
 Introduction to Embedded Systems

from the public or from a company (Generally speaking from an end

user/client). 'Need' should be articulated to initiate the Product Devel-
opment Life Cycle and based on the need for the product, a 'Statement
of Need' or 'Concept Proposal' is prepared. The 'Concept Proposal'
must be reviewed by the senior management and funding agency and
should get necessary approval. Once the proposal gets approval, it goes
to a product development team, which can either be ari orga~isation
from which the need arise or a third party product development/ser-
vice company (If a product development company approaches a client/
sponsor with the idea of a product, the business needs for the product
will be prepared by the company itself). The product development need
can be visualised in any one of the following three needs.
15.4.1. 1 New or Custom Product Development The need for a product which does not exist
in the market or a product which acts as competitor to an existing product in the current market will
lead to the development of a completely new product. The product can be a commercial requirement or
an individual requirement or a specific organisation's requirement. Example for an Embedded Product
which acts a competitor in the current market is 'Mobile handset' which is going to be developed by a
, new company apart from the existing manufacturers. A PDA tailored for any specific need is an example
for a custom product.
15.4.1.2 Product Re-engineering The embedded product market is dynamic and competitive.
In order to sustain in the market, the product developer should be aware of the general market trends,
technology changes and the taste of the end user and should constantly improve an existing product by
incorporating new technologies and design changes for performance, functionalities and aesthetics. Re-
engineering a product is the process of making changes in an existing product design and launching it
as a new version. It is generally termed as product upgrade. Re-engineering an existing product comes
as a result of the following needs.
1. Change in Business requirements
2. User Interface Enhancements
3. Technology Upgrades
15.4.1. 3 Product Maintenance Product maintenance 'need' deals with providing technical sup-
port to the end user for an existing product in the market. The maintenance request may come as a result
of product non-functioning or failure. Product maintenance is generally classified into two categories;
Corrective maintenance and Preventive maintenance. Corrective maintenance deals with making cor-
rective actions following a failure or non-functioning. The failure can occur due to damages or non-
functioning of components/parts of the product and the corrective maintenance replaces them to make
the product functional again. Preventive maintenance is the scheduled maintenance to avoid the failure
or non-functioning of the product.

15.4.2 Conceptualisation
Conceptualisation is the 'Product Concept Development Phase' and it begins
immediately after a Concept Proposal is formally approved. Conceptualisation
phase defines the scope of the concept, performs cost benefit analysis and feasi-
bility study and prepares project management and risk management plans. Con-
 The Embedded Product Development Lite Cycle (EDLC)

ceptualisation can be viewed as a phase shaping the "Need" of an end-user or convincing the end user,
whether it is a feasible product and how this product can be realised (Fig. 15.2). -

Analysis and estimation

(,~g.) ~;2) Y~riou~ ac:H~fi~s iit.vol\i'ed;ift c~~ceptua:li~ation Phase

The 'Conceptualisation' phase involves two types of activities, namely; 'Planning Activity' and
'Analysis and Study Activity'. The Analysis and Study Activities are performed to understand the op-
portunity of the product in the market (for a commercial product). The following are the important
'Analysis and Study activities' performed during 'Conceptualisation Phase'. ·
15.4.2.1 Feasibility Study Feasibility study examines the need for the product carefully and sug-
gests one or more possible solutions to build the need as a product along with alternatives. Feasibility
study analyses the Technical (Technical Challenges, limitations, etc.) as well as financial feasibility
(Financial requirements, funding, etc.) ofthe product under consideration.
15.4.2.2 Cost Benefit Analysis (CEA) The Cost Benefit Analysis (CBA) is a means of identify-
ing, revealing and assessing the total development cost and the profit expected from the product. It is
somewhat similar to the loss-gain analysis in business term except that CBA is an assumption oriented
approach based on some rule of thumb or based on the analysis of data available for similar products
developed in the past. In summary, CBA estimates and totals up the equivalent money value of the ben-
efits and costs of the product under consideration and give an idea about the worthwhile of the product.
Some common underlying principles of Cost Benefit Analysis are illustrated below.
.Commpn Unit of Measurement In order to make the analysis sensible and meaningful, all aspects
of the product, either plus points or minus points should be expressed in terms of a common unit. Since
 Introduction to Embedded Systems

the ultimate aim of a product is "Marginal Profit" and the marginal profit is expressed in terms of money
in most cases, 'money' is taken as the common unit of measurement. Hence all benefits and costs of the
product should be expressed in terms of money. Money in tum may be represented by a common cur-
rency. It can be Indian Rupee (INR) or US Dollar (USD), etc.
Market choice based benefit measurement Ensure that the product cost is justifying the money
(value for money), the end user is spending on the product to purchase, for a commercial product.
_,

Targeted end users For a commercial product it is very essential to understand the targeted end-
users for the product and their tastes to give them the best in the industry.
1S. 4.2.3 Product Scope Product scope deals with what is in scope (what all functionalities or tasks
are considered) for the product and what is not in scope (what all functionalities or tasks are not consid-
ered) for the product. Product scope should be documented properly for future reference.
1S.4.2.4 Planning Activities The planning activity covers various plans required for the product
devel9pment, like the plan and schedule for executing the next phases following conceptualisation, Re-
source Planning How many resources should work on the project, Risk Management Plans The
technical and other kinds of risks involved in the work and what are the mitigation plans, etc. At the end
of the conceptualisation phase, the reports on 'Analysis and Study Activities' and 'Planning Activities'
are submitted to the client/project sponsor for review and approval, along with any one of the following
recommendation.
1. The product is feasible; proceed to the next phase of the product life cycle.
2. The product is not feasible; scrap the project
The executive committee, to which the various reports are submitted, will review the same and will
communicate the review comments to the officials submitted the conceptualisation reports and will give
the green signal to proceed, if they are satisfied with the analysis and estimates.

15.4.3 Analysis
Requirements Analysis Phase starts immediately after the documents
submitted during the 'Conceptualisation' phase is approved by the
client/sponsor of the project. Documentation related to user require- ll
ments from the Conceptualisation phase is used as the basis for further .J
J

user need analysis and the development of detailed user requirements.

Requirement analysis is performed to develop a detailed functional mod-
el of the product under consideration. During the Requirements Analysis
Phase, the product is defined in detail with re$pect to the inputs, process-
es, outputs, and interfaces at a functional level. Requirement Analysis
phase gives emphasis on determining 'what functions must be performed
by the product' rather than how to perform those functions. The various
activities performed during 'Requirement Analysis' phase is illustrated
in Fig. 15.3.
1S.4.3.1 Analysis and Documentation The analysis -and documentation activity consolidates the
business needs of the product under development and analyses the purpose of the product. It address-
es various fon!Stiorial aspects (product features and functions) and quality attributes (non-functional
requirements) of the product, defines the functional and data requirements and connects the function-
 The Embedded Product Development Life Cycle (EDLC)

II
I

al requirements with the data requirements. In summary, the analysis activities address all business
functionalities of the product and d_evelop a logical model describing the fundamental processes and the
data required to support the functionalities. The various requirements that need to be addressed during
the requirement analysis phase for a product under consideration are listed below.
1. Functional capabilities like performance, operational characteristics (Refer to Chapter 3 for
de.tails on operational characteristics), etc.
2. Operational and non-operational quality attributes (Refer to Chapter 3 for Quality attributes of
embedded products)
3. Product external interface requirements
4. Data requirements
5. User manuals
6. Operational requirements
7. Maintenance requirements
8. General assumptions
1S.4.3.2 Interface Definition and Documentation The embedded product under consideration
may be a standalone product or it can be a part of a large distributed system. If it is a part of another
system there should be some interface between the product and the other parts of the distributed system.
Even in the case of standalone products there will be some standard interfaces like serial, parallel etc as
a provision to connect to some standard interfaces. The interface definition and documentation activity
should clearly analyse on the physical interface (type ofinterface) as well as data exchange through
these interfaces and should document it. It is essential for the proper information flow throughout the
life cycle.
1S.4.3.3 Defining Test Plan and Procedures Identifies what kind of tests are to be performed
arid.what all should be covered in testing the product. Define-the test-proceaures; test set1~il and test
 Introduction to Embedded Systems

environment. Create a master test plan to cover all functional as well as other aspects of the product
and document the scope, methodology, sequence and management of all kinds of tests. It is essential for
ensuring the total quality of the product. The vario:us types of testing performed in a product develop-
ment are listed below.
1. Unit testing-Testing each unit or module of the product independently for required functionality
and quality aspects
2. Integration testing-Integrating each modules and testing the integrated unit for required func-
tionality
3. System testing-Testing the functional aspects/product requirements of the product after integra-
tion. System testing refers to a set of different tests and a few among them are listed below.
• Usability testing-Tests the usability of the product
• Load testing-Tests the behaviour of the product under different loading conditions.
• Security testing-Testing the security aspects of the product
• Scalability testing-Testing the scalability aspect of the product
• Sanity testing-Superficial testing performed to ensure that the product is functioning prop-
erly
• Smoke testing-Non exhaustive test to ensure that the crucial requirements for the product
are functioning properly. This test is not giving importance to the finer details of different
functionalities
• Performance testing-Testing the performance aspects of the product after integration
• Endurance testing-Durability test of the product
4. User acceptance testing-Testing the product to ensur,e it is meeting all requirements of the end
user.
At the end, all requirements should be put in a _template suggested by the standard (e.g. ISO-9001)
Process Model (e.g. CMM Level 5) followed for the Quality Assurance. This document is referred
as 'Requirements Sp~cification Document'. It is sent out for review by the client and the client, after
reviewing the requirements specification document, communicates back with the review comments.
According to the review comments more requirement analysis may have to be performed and re-work
required is performed on the initial 'Requirement Specification Document'.

15.4.4 Design
Product 'Design phase' deals with the entire design of the product taking
the requirements into consideration and it focuses on 'how' the required
functionalities can be delivered to the product. The design phase identi-
fies the application environment and creates an overall architecture for
the product. Product design starts with 'Preliminary Design/High Level
Design'. Preliminary design establishes the top-level architecture for the
product, lists out the various functional blocks required for the product,
and defines the inputs and outputs for each functional block. The func-
tional block will look like a 'black box' at this design point, with only in-
puts and outputs of the block being defined. On completion, the 'Prelimi-
nary Design Document (PDD) is sent for review to the end-user/client
 The Embedded Product Development Life Cycle (EDLC)

who come up with a need for the product. If the end-user agrees on the preliminary design, the product
design team can take the work to the next level - 'Detailed Design'. Detailed design generates a detailed
architecture, identifies and lists out the various components for each functional block, the inter connec-
tion among v3:rious functional blocks, the control algorithm requirements, etc. The 'Detailed Design'
also needs to be reviewed and get approved by the end user/customer. If the end user wants modifica-
tions on the design, it can be informed to the design team through review comments.
An embedded product' is a real mix of hardware, embedded firmware and enclosure. Hence both
Preliminary Design and Detailed Design should take the design of these into consideration. For tradi-
tional embedded system design approach, the functional requirements are classified into either hard-
ware or firmware at an early stage of the design and the hardware team works on the design of the
required hardware, whereas the software team works on the design of the embedded firmware. Today
, the scenario is totally changed and a hardware software co-design approach is used. In this approach,
the functional requirements are not broken down into hardware and software, instead they are treated
as system requirements and the partitioning of system requirements into either hardware or software
is performed at a later stage of the design based on hardware-software trade-offs for implementing the
required functionalities. The hardware and software requirements are modelled using different model-
ling techniques. Please refer to Chapter 7 for more details on hardware-software co-design and program
models used in hardware-software co-design. The other activities performed during the design phase
are 'Design of Operations and maintenance manual' and 'Design of Training materials' (Fig. 15.4).
The operations manual is necessary for educating the end user on 'how to operate the product' and the
maintenance manual is essential for providing information on how to handle the product in situations
like non-functioning, failure, etc.

I
r
·.\

I
1i
j
l
Ma1titeninctf::' ·
tl lU~U,al Mirgn
i

(Fi,g~T$:4) t'Various Activities involved in Design Phase

 Introduction to Embedded Systems

C A I -Inputs
0 Outputs
C - Constraints
A Assumptions
I 0

C A

I 0

C A

I 0

C A
I Inputs
0 - Outputs
C - Constraints
I 0
A Assumptions
Cl, C2 - Component
IC Inter-connection
M Module

I 0

( Fig. lS.6) Detailed Des.ign Illustration

15.4.5 Development and Testing

The 'Development Phase' transforms the. design into a realizaple product. For
this the detailed specifications generated during the design phase are trans-
lated into hardware and firmware. During development phase, the installa-
tion .and setting up of various development tools is performed and the prod-
uct hardware and firmware is developed using different tools and associated
production setup. The development activities can be partitioned into embed-
 The Embedded Product Development Life Cycle (EDLC)

ded hardware development, embedded firmware development and product enclosure development. Em-
bedded hardware development refers to the development of the component placement platform - PCB
using CAD tools and its fabrication using CAM Tools. Embedded firmware development is performed
using the embedded firmware development tools. The mechanical enclosure design is performed with
CAD Tools like Solid Works, AutoCAD, etc. "Look and Feel" of a commercial product plays an impor-
tant role on its market demand. So the entire product design and development should concentrate on the
product aesthetics (Size, Weight, Appearance, etc.) and special requirements like protection shielding,
etc.
Component procurement also carried out during this phase. As mentioned in one of the earlier chap-
ters, some of the components may have "lead time - The time required for the component to deliver
after placing the purchase order for the component" and the component procurement should be planned
well in advance to avoid the possible delay in the product development. The other important activities
carried out during this phase are preparation of test case procedures, preparation of test files and de-
velqpment of detailed user, deployment, operations and maintenance manual. The embedded firmware
development may be divided into various modules and the firmware (code) review for each module as
well as the schematic diagram and layout file review for hardware is carried out during the development
phase and the changes required should be incorporated in the development from time to time.
The testing phase can be divided into independent testing of firmware and hardware (Unit Testing),
testing of the product after integrating the firmware and hardware (Integration Testing), testing of the
whole system on a functionality and non-functionality basis (System Testing) and testing of the product
against all acceptance criteria mentioned by the client/end user for each functionality (User Acceptance
Testing). The Unit testing deals with testing the embedded hardware and its associat~d modules, the
different modules of the firmware for their functionality independently. A test plan is prepared for the
unit testing (Unit Test plan) and test cases (Unit Test cases) are identified for testing the functionality of
the product as per the design. Unit test is normally performed by the hardware developer or-..finnware
developer as part of the development phase. Depending on the product complexity, rest of the tests
can be considered as the activities performed in the 'Testing phase' of the product. Once the hardware
and firmware are unit tested, they are integrated using various firmware integration techniques and the
integrated product is tested against the required functionalities. An integration test plan is prepared for
this and the test cases for integration testing (Integration test cases) is developed. The Integration testing
ensures that the functionality which is tested working properly in an independent mode remains work-
ing properly in an integrated product (Hardware + Firmware). The integration test results are logged in
and the firmware/hardware is reworked against any flaws detected during the Integration testing. The
purpose of integration testing is to detect any inconsistencies between the firmware modules units that
are integrated together or between any of the firmware modules and the embedded hardware. Integration
testing of various modules, hardware and firmware is done at the end of development phase depending
on the readiness of hardware and firmware.
The system testing follows the Integration testing and it is a set of various tests for functional and
non-functional requirements verification. System testing is a kind of black box testing, which doesn't
require any knowledge on the inner design logic or code for the product. System testing evaluates the
product's compliance with the requirements. User acceptance test or simply Acceptance testing is the
·1 product evaluation performed by the customer as a condition of the product purchase. During user Ac-
ceptance testing, the product is tested against the acceptance value set by customer/end user for each
requirement (e.g. The loading time for the application running on the PDA device is less than 1 mil-
l. lisecond ©). The deliverables from the 'Design and Testing' phase are firmware source code, firmware
1 binaries, finished hardware, various test plans (Hardware and Firmware Unit Test plans, Integration Test
\ plan, System Test plan and Acceptance Test plan), test cases (Hardware and Firmware Unit Test cases,
 Introduction to Embedded Systems

Integration Test cases, System Test cases and Acceptance Test cases) and test reports (Hardware and
Firmware Unit Test Report, Integration Test Report, System Test Report and Acceptance Test Report).

15.4.6 Deployment
Deployment is the process of launching the first fully functional model of the
product in the market (for a commerciatembedded prnduct) or handing over
the fully functional initial model to an enduser/clientlt is also known as First
Customer Shipping (FCS). During this phase, the'prOduct modifications as per
the various integration tests are implemented and iliefproduct is made opera-
tional in a production environment. The 'Deployinent;Phase' is initiated after
the system is tested and accepted (User Acceptance'Test)bythe end user. The
important tasks performed during the Deployment Phase are listed below.
15.4. 6.1 Notification of Product Deployment . Whenever the product is ready to launch in the
market, the launching ceremony details should be communicated to the stake holders (all those who are
related to the product in a direct or indirect way) aµd to the public if it is a commercial product. The
notifications can be sent out through e-mail, media, etc. mentioning the following in a few words.
1. Deployment Schedule (Date Time and Venue)
2. Brief description about the product
3. Targeted end users
4. Extra features supported with respect to an existing product (for upgrades of existing model and
new products having other competitive products in the market)
5. Product support information including the support person name, contact number, contact mail ID,
etc.
15. 4. 6. 2 Execution of Training Plan Proper training should be given to the end user to get them
acquainted with the new product. Before launching the product, conduct proper training as per the train-
ing plan developed during the earlier phases. Proper training will help in reducing the possible damages
to the product as well as the operating person, including personal injuries and product mal-functioning
'due to inappropriate usage. User manual will help in understanding the product, its usage and accessing
its functionalities to certain extend.
15.4. 6.3 Product Installation Instal the product as per the installation document to ensure that it
is fully functional. As a typical example take the case of a newly purchased mobile handset. The user
manual accompanying it will tell you clearly how to instal the battery, how to charge the battery, how
many hours the battery needs to be charged, how the handset can be switched on/off, etc.
15.4.6.4 Product post-Implementation Review Once the product is launched in the market,
conduct a post-implementation review to determine the success of the product. The ultimate aim behind
post-implementation review is to document the problems faced during installation and the solutions
adopted to overcome them which will act as a reference document for future product development. It
also helps in understanding the customer needs and the expectations of the customer on the next version
of the product.

15.4.7 Support
The support phase deals with the operations and maintenance of the product in a production environ-
ment. During this phase all aspects of operations and maintenance of the product are covered and the
 The Embedded Product Development Life Cycle (EDLC)

product is scrutinised to ensure that it meets the requirements put forward by the
1 end user/client. 'Bugs (product mal-functioning or unexpected behaviour or any
operational error)' in the products may be observed and reported during the op-

l erations phase. Support should be provided to the end user/client to fix the bugs
in the product. The support phase ensures that the product meets the user needs
and it ·continues functioning in the production environment. The various activities
involved in the 'Support' phase are listed below.
15.4. 7.1 Set up .a Dedicated Support Wing The availability of certain embedded products in
terms of product functioning in production environment is crucial and they may require 24x7 support in
case of product failure or malfun~tioning. For example the patient monitoring system used in hospitals
is a very crjtical product in terms of functioning and any malfunctioning of the product requires immedi-
ate technical attention/support from the supplier. Set up a dedicated support wing (customer care unit)
and ensure high quality service is delivered to the end user. 'After service' plays significant role in prod-
uct movement in a commercial market. If the manufacturer fails to provide timely and quality service to
the end user, it will naturally create the talk 'the product is good but the after service is very poor' among
the end users and people will refrain from buying such products and will opt for competitive products
which provides more or less saine functionalities and high quality service. The support wing should be
set up in such a way that they are easily reachable through e-mail, phone, fax, etc.
15.4. 7.2 Identify Bugs and Areas of Improvement None of the products are bug-free. Even if
you take utmost care in design, development and implementation of the product, there can be bugs in it
and the bugs reveal their real identity when the conditions are favouring them, similar to the harmless
microbes living in human body getting turned into harmful microbes when the body resistance is weak.
You may miss out certain operating conditions while design or development phase and if the product
faces such an operatmg condition, the product behaviour may become unexpected and it is addressed
with the familiar nick name 'Bug' by a software/product engineer. Since the embedded product market
is highly competitive, it is very essential to stay connected with the end users and know their needs for
the survival of the product. Give the end user a chance to express;,their views on the product and sug-
gestions, if any, in terms of modifications required or feature enhancements (areas of improvement),
through user feedbacks. Conduct product specific surveys and collect as much data as possible from the
end user.

15.4.8 Upgrades
The upgrade phase of product development deals with the development of up- ,
grades (new versions) for the product which is already present in the market.
Product upgrade results as an output of major bug fixes or feature enhancement
requirements from the end user. During the upgrade phase the system is subject
to design modification to fix the major bugs reported or to incorporate the new
feature addition requirements aroused during the support phase. For embed-
ded products, the upgrades may be for the product resident firmware or for the
hardware embedding the firmware. Some bugs may be easily fixed by modifying the firmware and it
is known as firmware up-gradation. Some feature enhancements can also be performed easily by mere
firmware modification. The product resident firmware will· have a version number which starts with
version say 1.0 and after each firmware modification or bug fix, the firmware version is changed accord-
ingly (e.g. version 1.1 ). Version numbering is essential for backward traceability. Releasing of upgrades
 Introduction to Embedded Systems

is managed through release management. (Embedded Product Engineers might have used the term
"Today I have a release" at least once in their life). Certain feature enhancements and bug fixes require r
hardware modification and they are generally. termed as hardware upgrades. Firmware also needs to be r
modified according to the hardware enhancements. The upgraded product appears in the market with the l a
same name as that of the initial product with a different version number or with a different name. t
j r
15.4.9 Retirement/Disposal
I
1:
r
We are living in a dynamic world where ev~rything is.subject to rapid changes.
The technology you feel as the most advanced and best today may not be the
r
C
same tomorrow. Due to increased user needs and revolutionary technological C
changes, a product cannot sustain in the market for a long time. The disposal/
f
retirement of a product is a gradual process: When the product manufacture C
realises that there is another powerful technology or component available. in the t
market which is most suitable for the production of the current product, they V
will announce the current product as obsolete and the newer version/upgrade of the same is going to be tl
released soon. The retirement/disposition phase is the final phase in a product development life cycle V
where the product is declared as obsolete and discontinued from the market. There is no meaning and
i::
monetary benefit in continuing the production of a device or equipment which is obsolete in terms of
technology and aesthetics. The disposition of a product is essential due to the following reasons.
I. Rapid technology advancement
2. Increased user needs
Some products may get a very long 'Life Time' in the market, beginning from the launch phase to
the retirement phase and during this time the product will get reasonably good amount of maturity and
stability and it may be able to create sensational waves in the market (e.g. Nokia 3310 Mobile Handset;
Launched in September 2000 and discontinued in eany2005, more than 4 years of continued presence
in the market with 126 million pieces sold). Some products get only small 'Life Time' in the market and
some of them even fails to register their appearance in the market.
By now we covered all the phases of embedded product development life cycle. We can correlate the
various phases of the product development we discussed so far to the various activities involved in our
day-today life. Wbenever you are a child you definitely have the ambition to become an earning person
like your mom/dad (There may be exceptions loo ©). The need for a job arises here. To get a good job
you must have a good academic record and hence you should complete the schooling with good marks
and should perform very well in interviews. Finally you are managed to get a good job and your profes-
sional career begins here. You may get promotions to next senior level depending on your performance.
At last that day comes-Your retirement day from your professional life ..

The term 'Modelling' in Embedded Product Development Life Cycle refers to the interconnection of
various phases involved in the development of an embedded product. The various approaches adopted
or models used in Modelling EDLC are described below.

15.5.1 Linear orWaterfall Model

Linear or waterfall approach is the one adopted in most of the olden systems and in this approach each
C
\ The Embedded Product Development Life Cycle (EDLC)

\ phase of EDLC is executed in sequence. The linear model establishes a formal analysis and design
j
i
I methodology with highly structured development phases. In linear model, the various phases ofEDLC
i are executed in sequence and the flow is unidirectional with output of one phase serving as the input to
l the next phase. In the linear model all activities involved in each phase are well documented, giving an
insight into what should be done in the next phase and how it can be done. The feedback of each phase

'i is available locally and only after th~y are executed. The linear model implements extensive review
mechanisms to ensure the process flow is going in the rigJ:it direction and validates the effort during a
phase. One significant feature of linear model is that even if you identify bugs in the current design, the
corrective actions are not implemented immediately and the development process proceeds with the
current design. The fixes for the bugs are postponed till the support phase, which accompanies the de-
ployment phase. The major advantage of 'Linear Model' is that the product development is rich in terms
of documentation, easy project management and good control over cost and schedule. The major draw-
back of this approach is that it assumes all the analysis can be done and everything will be in right place
without doing any design or implementation. Also the risk analysis is performed only once throughout
the development and risks involved in any changes are not accommodated in subsequent phases, the
working product is available only at the end of the development phase and bug fixes and corrections are
performed only at the maintenance/support phase of the life cycle. 'Linear Model' (Fig.15.7) is best

Statement of Need

System boundary definition,

CBAReport

Requirements gathering

Preliminary and
detailed design

j Hardware and finnware Uniti1ntegration/

1 development System testing
1
l
1
Product launching

Maintenance and bug fixes

II
l Product upgrades

\
lj
Product disposal

I
1 1
 Introduction to Embedded Systems

suited for product developments, where the requirements are well defined and within the scope, and no
change requests are expected till the completion of the life cycle.

15.5.2 Iterative/Incremental or Fountain Model

Iterative or fountain model follows the sequence-Do some analysis, follow some design, then some
implementation. Evaluate it and based on the shortcomings, cycle back through and conduct more anal-
ysis, opt for new design and implementation and repeat the cycle till the requirements are met complete-
ly. The iterative/fountain model can be viewed as a cascaded_ series of linear (waterfall) models. The
incremental model is a superset of iterative model where the requirements are known at the beginning
and they are divided into different groups. The core set of functions for each group is identified in the
first cycle and is built and deployed as the first release. The second set of requirements along with the
bug fixes and modification for first release is carried out in the second cycle and the process is repeated
until all functionalities are implemented and they are meeting the requirements. It is obvious that in an
iterative/incremental model (Fig. 15.8), each development cycle act as the maintenance phase for the I
(
previous cycle (release). Another approach for the ·iterative/interactive model is the 'Overlapped' model
where development cycles overlap; meaning subsequent iterative/incremental cycle may begin before
the completion of previous cycle.·

- 1
t
t
r
1

(
 The Embedded Product Development Life Cycle (EDLC)

If you closely observe this model you can see that each cycle is interconnected in a similar fashion
of a fountain, where water first moves up and then comes down, again moves up and comes down. The
major advantage of iterative/fountain model is that it provides very good development cycle feedback at
each function/feature implementation and hence the data can be used as a reference for similar product
development in future. Since each cycle can act as a maintenance phase for previous cycle, changes in
feature and functionalities can be easily incorporated during the dev_elopment and hence more respon-
sive to changing user needs. The iterative model provides a working product model with at least mini-
mum features at the first cycle itself. Risk is spread across each individual cycle and can be minimised
easily. Project management as well as testing is much simpler compared to the .linear model. Another
major advantage is that the product development can be stopped at any stage with a bare minimum
working product. Though iterative model is a good solution for product development, it possess lots of
drawbacks like·extensive review requirement at each cycle, impact on operations due to new releases,
training requirement for each new deployment at the end of each development cycle, structured and well
documented interface definition across modules to accommodate changes. The iterative/incremental
model is deployed in product developments where the risk is very high when the development is carried
out by linear model. By choosing an iterative model, the risk is spread across multiple cycles. Since
each cycle produces a working model, this model is best suited for product developments where the
continued funding for each cycle is not assured.

15.5.3 Prototyping/Evolutionary Model

-· Prototyping/evolutionary model is similar to the iterative model and the product is developed in mul-
tiple cycles. The only difference is that this model produces a more refined prototype of the product at
the end of each cycle instead of functionality/feahire addition in each cycle as performed by the iterative
model. There won't be any commercial deployment of the prototype of the product at each cycle's end.
The shortcomings of the pro to-model after each cycle are evaluated and it is fixed in the next cycle.

Design Prototyping

Initial prototype
/-(
/
Refined design "f'
'
Primary design+

/
:i>-- Evaluation and
Refined requirement and plan ;:. /
/
feedback
/
Initial requirement and plan ,Jt. -- + Final product

Analysis and planning Customer

 Introduction to Embedded Systems

After the initial requirement analysis, the design for the first prototype is made, the development
process is started. On finishing the prototype, it is sent to the customer for evaluation. The customer
evaluates the product for the set of requirements and gives his/her feedback to the developer in terms of
shortcomings and improvements needed. The developer refines the product according to the customer's
exact expectation and repeats the proto development process. After a finite number of iterations, the
final product is delivered to the customer and launches in the marke1/operational environment. In this
' approach, the product undergoes significant evolution as a result of periodic shuttling of product infor-
mation between the customer and developer. The prototyping model follows the approach 'Require-
ments definition, proto-type development, proto-type evaluation and requirements refining'. Since the
requirements undergo refinement after each proto model, it is easy to incorporate new requirements
and technology changes at any stage and thereby the product development process can start with a bare
minimum set of requirements. The evolutionary model relies heavily on user feedback after each imple-
mentation and hence finetuning of final requirements is possible. Another major advantage of proto-:-typ-
ing model is that the risk is spread across each proto development cycle and it is well under control. The
major drawbacks of proto-typing model are
1. Deviations from expected cost and schedule due to requirements refinement
2. Increased project management
3. Minimal documentation on each prototype may create problems in backward prototype
traceability
4. Increased Configuration Management activities
Prototyping model is the most popuilar product development model adopted in embedded product
industry. This approach can be considered as the best approach for products, whose requirements are
not fully available and are subject to change. This model is not recommended for projects involving the
up gradation of an existing product. There can be slight variations in the base prototyping model depend-
ing on project management.

15.5.4 Spiral Model

Spiral model (Fig. 15 .10) combines the elements of linear and prototyping models to give the best pos-
sible risk minimised EDLC Model. Spiral model is developed by Barry Boehm in 1988. The product
development starts with project definition and traverse through all phases of EDLC through multiple .
phases. The activities involved in the Spiral model can be associated with the four quadrants of a spiral
and are listed below.
1. Determine objectives, alternatives, constraints.
2. Evaluate alternatives. Identify and resolve risks.
3. Develop and test.
4. Plan.
Spiral model is best suited for the development of complex embedded products and situations where
requirements are changing from customer side. Customer evaluation of prototype at each stage allows
addition of requirements and technology changes. Risk evaluation in each stage helps in risk planning
and m~tigation. The proto modei developed at each stage is evaluated by the customer against various
parameters like strength, weakness, risk, etc. and the final product is built based on the final prototype
on agreement with the client.
\
The Embedded Product Development Life Cycle (EDLC)

Objective, Alternative and Evaluate Alternatives and Risks

Constraints

I ~-,--....._

Alternative and constraints

I & T plan Validation and

- - - - 1 - verfication

Planning Design and Verification

''foQycle ....
,$liq Prodtic;f
tivities a.mo
!idev~l~~R!~
,~<1,guality~t....,.,'f>•• . ·. ,. ,, . .:,,f' ·' 'i
provemenfand enstJnqgquality'. ;•· J5r?dut;tar: '\ ;,.,-'},::- '-"': ..

.• -I'; :f ..·,. .... .,,~qpqgem~vt:is ,e~sential-fqr predictability, CO-'Ordination and ris~ mif,iiihisi1aht~:p~&ii~it~eyelop!l1ent
. ✓-·:'Tll~·:ijj{~'\Cyc;ie of a.pr~qrict aeyelopment is commonly referred as Mcidels'<!~d 1'1odel defines the variqus a
,·:plillSei)irifolvedinapr,9tiuc;t'SJltfe,cycle ·. . . ,.< ., ·'· ', ·' ·
;si'2:E~b,~t · 1tifi!U4ltLife Gycle Model contains thepha~es: Need, C~ncefti~dliiation,Analysis, Desigri,
·, 'iijenti,md· .... 11g,Deplo!ment, Support, Upgrades and Ren'reinentllJi~posai. ·. ·
, . ';pfq4µct4ew~lqpri:lintpee?t'.f~ls i,nto three categories namely, New;o;c~stoni prodµtt dev~loplllept, Product
; ' ·t~~l<hgint1ering an(!
prod~ct:niaiµteiance . . . . .. ...· ',; . . '
✓ Coniepi,alisation pha~e i.s... the . pha~e dealing with product concept. development. Cbnceptualisation phase
. •; m,9l~4-~~-ictivities lilce pr,oduct 'feasibility analysis, cost_:benefit analysis, -prooyct-sbcipjng;"anfpla~ing for nexJ
,..'\'·~_-"''z;;')t,:f:'J<t ·< ]···"···:" ' " . -·, _"·,_,;•·\ ·"'. .- . ,.·. ·'/-{ . .• --. •' ;" ,· ' • , ;'

\_, . " . _.. _••'. :< <,,, • .__ ___ ? _ ,. , ••.,,,-: •.. -_,_{',::,,:,·: ··~·::.:,/s··-:_: _ ,/ k-•'v _:~·:-> ·_ . ..
··m~n,tspi14ly~is p&a~e,.:defines the mputs, processes, 'outputs; ~i)d,111:tetf'a()~S, :qfr'the product at._a
::AiJ~1~ii~';;n4:'dqcilinerttation, interfac~ defil\lltioifan§ do~ · ~Hta:~ 'gb'.•t~iMttest'.plah ahd
. :;)~t,f.~f·t~(*cHvities carried '6ut auringrequireirt~n, . • .. 't.\' ··t-r;t•; •·~is,·
iph~se~~als.wiW,;t~: 1mplementatiori aspects of the re,quired:fu11cii ··. r·t~~~roduct ·. .
·::~~$.!~
,#§tij~\!~~¢~ '.the top-level ,arcfiltectµre· for:tlie'·pro1ri€(ii ':Zr:citiJs:ifuhctiorial
.for.:i\iepr9duc't,'~~ddefines the inputs arid putputs;1tgf\~aph:UW~Jif . ' . ·i
esign';genetates ii ·d~tailed architecture,· identifies:andiifsJs:iQUJ;\~~-· ,M{cft~z~~f!1
tll~
funbtit>nal. bldck, irlt~l'-'COni1ebtl~n among various functional blocki;~tb'e'c~rit;ol a g t~qqrrerp.ent,s, etc. '
 Introduction to Embedded Systems

✓ The Development phase transforms the design into a realisable product. The detailed specifications generated
during the design phase are translated into hardware and firmware during the development phase
✓ The Testing pha~e deals with the execution of various tests like Integration testing, System testing, User
acceptance testing, etc.
✓ The Deployment phase deals with the launching of the product. Product deployment notification, Training plan
. execution, product installation, Product post-implementation review, etc. are the activities performed during
Deployment phase
✓ The Support phase deals.with the.operations and maintcnaqc~ of th~ product in a production environment
✓ The Upgrade phase of product qevelopment d~als,'Yith the,development of upgrades (new versions) £or th~:
product which is already present ID the :mqrket..Product upgrade reslllt'l as an output of major.bug fixes or fel:!tuIQ
· enhancement requirements from the end user .. . ..
✓ Retirement/Disp:Osal phase of a product deals ·with the gradl!:al dispCJsal of a product from the market
✓ Linear or Wate,fall,Iter,(Jtiv.e or incremen~al or jountain,R~ototyping or evohitiona1y and Spiral models are the
COlllIDOllly usediEDLC models in embedded product development •
. ✓ The Linear or Tfaterfall model executes all phases .of the EDLC in sequence, one after another. It is the beii;
suited method f6r product (ievelopment·where the requirements are fixed ..
✓ Iterative or Fo~nt~in · rriodel follows the sequence-Do some analysis, follow ~ome design, then soml;
implementation. Evaluate it and based on.the short comings, cycle back through and con~pct more analysJs,~Pt:
for new design and implementation and repeat the cycle till the requirements are met completely. · ' · :<.0;\1}~~
✓ Prototyping model is a variation to the Iterative model, in which a more refined prototype is produced at thyJ~f
of each iteration. '!tis the best suited model for developing emJ1~dped products whose requirements are not fuily'
available at the time of starting the project, and ~re subj~f,t to:6hhlige
✓ Spiral modei is the EDLC model combining linear and prototyping model to give the best possible
,, ,minimisatioQ. jQ. pr9dµ<;t development

~Keywords]
Embedded Product An 'Analysis-Design-Implementation' based standard problem solving approach for
Development Life Cycle Embedded Product Development
(EOLC) ,
Model The various phases involved in a product development life cycle
Need Demand for a custom product or re-engineering of an existing product or maintenance
of an existing product
Conceptualisation Product Life Cycle stage which deals with the concept development for a product
Requirement.Analysis Product Life Cycle stage which deals with the activities for developing a detailed
functional
,, . model of the product under consideration
Design Phase Product Life Cycle stage which deals with the implementation aspects of the required
fµnctionalities for the product
I>evel9P,ment Ph"ase .. ~roduct Life Cycle stage which transfonns the design into a realisable product
Testing Phase P,:hase which deals with the execution of various tests like Integration testing, System
testing, User acceptance testing. etc,
Unit Testing Tests carried out to verify the functioning of the individual modules of the firmware
and hardware
Integration Testing Tests c~Tied out to verify the functioning of a product for the required functionalities
after thi integration of embedded firmware and hardware
 The Embedded Product Development Life Cycle (EDLC)

Objective Questions
1. Which of the following is not in the scope of EDLC
(a) Maximise Return on Investment (RoI)
(b) Minimise the risks involved in the product development
(c) Advertise the product
(d) Defect prevention in Product development
2. The term 'model' in EDLC represents
(a) The various phases in the life cycle of the product (b) The various analysis of the product
(c) The various designs of the product (d) The various architecture of the product
3. Which of the following is(are) a driving factor(s) for 'Product Re-engineering'?
(a) Change in business requirement (b) User interface enhancements
(c) Technology upgrades (d) All of these
ww~w oow~~
4. An embedded product requires interfacing with another subsystem of an enterprise for data logging and information
exchange. The interface for this is defined during?
(a) Conceptualisation phase (b) Requirement analysis phase
(c) Design phase (d) Development phase
(e) Deployment phase
5. An embedded product requires a TCP/IP interface and it is decided that the TCP/IP interface can be implemented
using Commercial of the Shelf (COTS) component. The COTS module for the TCP/IP Module is finali,Sed and
selected during?
\ (a) Conceptualisation phase (b) Requirement analysis phase
(c) Design phase (d) Development phase
(e) Deployment phase

\
 Introduction to Embedded Systems

. 6. An embedded product contains LCD interfacing and a developer is assigned to work on this module. The developer
coded the module and tested its :functioning using a simulator. The test performed by the developer falls under?
(a) Integration Testing (b) Unit Testing
(c) System Testing (d) Acceptance Testing
7. For an Embedded product, the requirements are well defined and are within the scope and no change requests
are expected till the completion of the life cycle. Which is the best-suited life cycle model for developing this
product?
(a) Linear (b) Iterative (c) Prototyping (d) Spiral
8. Which of the following is(are) not a feature of prototyping model
(a) Requirements refinement (b) Documentation intensive
(c) Intensive Project Management (d) Controlled risk
9.. An embedded product under consideration is very complex in nature and there is a possibility for change in
requirements of the product. Also the risk associated with the development of this product is very high. Which is
the best-suited life cycle method to handle this product development?
(a) Linear (b) Iterative (c) Prototyping (d) Spiral

Review Questions
I. What is EDLC? Why EDLC is essential in embedded product development?
2. What are the objectives of EDLC?
3. Explain the significance of Productivity in embedded product development. Explain the techniques for productivity
improvements
4. Explain the different phases of Embedded Product Development Life Cycle (EDLC)
5. Explain the term 'model' in relation to EDLC
6. Explain the different types of Product Development needs
7. Explain the Product Re-engineering need in detail
8. Explain the various activities performed during the Conceptualisation phase of an Embedded product
development.
9. Explain 'the various activities performed during the Requirement Analysis phase of an embedded product
development.
10. Explain the various activities performed during the Design phase of an embedded product development.
11 .. Explain the various activities performed during the Development phase of an embedded product development.
12: Explain the various types of tests performed in the development of an embedded product.
13. ·Explain the various activities performed during the Deployment phase of an embedded product.
14. Explain the various activities performed during the Support phase of an embedded product.
15. Explain the need for Product upgrades in the Embedded Product development. Explain the different types of
product upgrades.
16. Explain the various factors leading to the Retirement/Disposal of an embedded product
17. Explain the different Life Cycle Models adopted in embedded product development
18. Explain the merits and drawbacks of Linear model for embedded product development
19. Explain the similarities and differences between Iterative and Incremental life cycle model
20. Explain the merits and drawbacks of Fountain model for embedded product development
21. Explain the similarities and differences between Iterative and Evolutionary life cycletfnodel
22. Explain the merits and drawbacks of Prototyping model for embedded product develbpment
23. Explain the need for Spiral life cycle model in embedded product development
From the first mass produced embedded system, Autonetics D-17, to the recently launched Apple
iPhone1, the embedded industry has evolved a lot, in terms of miniaturisation, performance, features,
development cost and time to market. This book will not be complete without throwing some light into
the current trends and bottlenecks in the embedded development.

16.l PROCESSOR TRENDS IN EMBEDDED SYSTEM

· -., · ·• ,"' s· '·' '•;· • "; · · ,, ' • · ·· • • ,,v

Indeed, the advances in the processor technology are the prime driving factor in the embedded devel-
opment arena. In the 1970s we started developing our embedded devices based on the 8bit micropro-
cessors/controllers. Later we moved to 'the 16 and 32bit processor based designs, depending on our
t Apple iPhone was the sensational gadget in the embedded device market at the time of writing this book (Year 2008-09).
 Introduction to Embedded Systems

system requirement, as and when they appear in the market. Even today the 8bit processors/controllers
are widely used in low-end applications. The only difference between the olden days 8bit processors/
controllers and today's 8bit processors/controllers is that today's 8bit processors/controllers are more
power and feature packed. In the olden days we used 'n' number ofICs for building a device, but today,
with the high degree of integration and I? Core re-use techniques, processors/controllers are integrating
rnultiple IC functionalities into a single chip (System on Chip). In the olden days we required a proces-
sor/controller, Brown out circuit, reset circuit; watch dog timer ICs, and ADC/DAC ICs·separately for
building a simple Data Acquisition System, today a single microcontroller with all these components
integrated is available in the market and it leads to the concept of miniaturisation and cost saving. Em-
bedded industry has also witnessed the architectural changes for processors. In the beginning of the
processor revolution, the speed at which an 8085 microprocessor executing a piece of code was awe-
some to us. Because it was beyond our imaginations. As we experienced the performance enhancements
offered by general computing processors like x86, P-I, P-II, P-III, P-IV, Celeron, Centrino and Core
2 Duo, today we are unsatisfied with the performance offered by even the most powerful processor,
because we have witnessed the rapid growth in the processor technology and our expectations are sky
high today. Reduced Instruction Set Computing (RISC) and execution pipelining contributed a lot to
the improvement on processor performance. From the procedural execution, the processor architecture
moved to the single stage instruction pipelining and today processor families.like ARM are supporting
8-stage pipelining (The latest ARM family ARMll at the time of writing this book) with instruction and
data cache.
The operating clock frequency was a bottleneck in processor designs. The earlier versions of proce~-
sors/controllers were designed to operate at a few MHz. Advances in the semiconductor technology has
elevated the bar on the operating frequency limitations. Nowadays processors/controllers with operat-
ing frequency in the range of Giga hertz (GHz) are available. Indeed, increase in operating frequency
increases the total power consumption. Another trend in the embedded processor market is the 'Device
oriented' design of processors. As mentioned earlier, in the beginning of the embedded revolution, we
started building our embedded products around the available processors/controllers. As embedded in-
dustry started gaining momentum, the need for device specific processor design is flagged ?,nd processor
manufactures started thinking in that direction. Today, when we think about developing a product, say
Set Top Box or Handheld Device, we have a bunch of processors to select for the design. Intel is offering
a variety of device specific processors. In~el PXA family of StrongARM processor (Now owned by Mar-.
vell Technology Group) is specifically designed for PDA applications and Intel has an x86 version for
Set Top Box devices. The following section gives an overview of the key processor architecture/trends
in embedded development.

16 .1.1 System on Chip (SoC).

As the name indicates, a System on Chip (SoC) makes a system on a single chip. The System on Chip
technology places multiple function 'system_s' on a single chip. As mentioned earlier, in the beginning
of the embedded revolution, we used separate ICs in an interconnected fashion for implementing a sys-
tem. Innovations in the semiconductor area introduced the concept of integration of multiple function
'systems' on a single chip. With this it is possible to integrate almost all functional systems required to
build an embedded product into a single chip. SoCs changed the concept of embedded processor from
general purpose design to device specific design. Nowadays SoCs are available for diverse application
needs like Set Top Boxes, Portable media players, PD As, etc. iMX3 l SoC from freescale semiconductor
 Trends in the Embedded Industry

is a typical example for SoC targeted for multimedia applications. It integrates a powerful ARM 11 Core
and other system functions like USB OTG interface, Multimedia and human interface (Graphics Ac-
celerator, MPEG 4, Keypad Interface), Standard Interfaces (Timers, Watch Dog Timer, general purpose
1/0), Image Processing Unit (Camera Interface, Display/TV control, Image Inversion and rotation, etc.)
etc. on a single silicon wafer. On a first look SoC and Application Specific Integrated Circuit (ASIC)
· resembles the same. But they are not. SoCs are built by integrati_ng the proven reusable IPs of differ-
ent sub:.systems, whereas ASICs are IPs developed for a specific application. By integrating multiple
functions into a single chip, SoCs greatly save the board space in embedded hardware development and
thereby leads to the concept of miniaturisation. SoCs are also cost effective.

16.1.2 iyiulticore Processors/Chiplevel Multi Processor (CMP)

One way of achieving increased performance is to increase the operating clock frequency. Indeed it
will increase the speed of execution with the cost of high power consumption. In today's world most
embedded devices are demanding battery power source for their operation. Here we don't have the
luxury to offer high performance with the cost of reduced battery life. Here comes the role of Multicore
processors. Multicore processors incorporate multiple processor cores on the same chip and works on
the same clock frequency supplied to the chip. Based on the number of cores, the processors are kn9'0-'n
as dual core (2 cores), tri core (3 cores), quad core (4 cores), etc. Multicore processors impleI11.erit
multiprocessing (Simultaneous execution. Don't confuse it with multitasking). Each core of the CMP
implements pipelining, multithreading and supersc_alar execution. Current imple!r.epta..i,i,o~sf Ih!~l of
multic9re processors support cores up to 4, whereas Freescale multi core processors sµpport coresup tP
2. It is amazing to note that the multicore processor OCTEON™ CN3860, deVelbpecl byCavhifu Net-
works (http://www.caviumnetworks.com) is supporting 16 MIPS'.pfocessor cores capa:bie ofbperating
at a clock frequency of 1GHz. '

16 .1. 3 Reconfigurable Processors·

Reconfigurable processor is a micrqprocqs,~Rr/c911tr91Jer~with;rec9µfigprahly1har_dwt1re features. They
contain an array of Programming Elements (PE)afong wlih a microprocess.or (Typically a RISC proces-
sor). The PE can be either .a computational engine or a memory element. The hardware feature of the
reconfigurable processor can be changed statically or dynamically. The dynamic changing of hardware
configuration brings the a,dvantage of making the chip adaptable to .the firmware running on the pro-
cessor. Depending on the situational-need, thereconfigurable processor can.entirely change their func-
tionality to adaptto the new requirements. For example, a chip.can configure itself to function as the
heart of a camera system or a media player in a single device by downloading the appropriate firmware.
Billions of Operations and Chameleon Systems are the key. players of reconfigurable processor mar-
ket. Reconfigurable SoCs (RSoCs) implement the IP for different subsystems through a reconfigurable
matrix. This enables configurable hardware functionality for an SoC. The SoC needs to.be configured
to the required harq.ware functionc;t_lity; through software support at the time .of system initialisation
(startµp task). The hardware configuration can also be ch~nged on the fly, A typical example for this is
configµring the hardware cod~c for the required compression like MPEG 1, MPEG 2, etc. by a media
player application on a need basis. The Field Programmable System Level Integrated Circuit (FPSLIC)

trhe statistics shown here is based on the data available till'Dec 2008. Since processor tecnnoiogy'is undergoing rapid changes, this data
may not be relevant in future.
 Introduction to Embedded Systems

from Atmel Corporation is a typical example for RSoC. It integrates an 8bit AYR processor and a dy-
namically reconfigurable Field Programmable Gate Array (FPGA). The system is reconfigured from a
library of pre-compiled IP cores stored in a FLASH memory on a need basis. RSoCS bring the concept
of silicon sharing and thereby leads to less silicon usage and low power consumption.

\;?J16}~f;,;;~~~ij~~ ,·,j®D,~~~:'.?\tt11~.~:,):.:~;1~~;i.+,:.'.));,-::.~;~~;<;;::<i,•J:~.}:~ <:i<'.>·, ·~:-:r,.,:~,:: . ·___ .

The Embedded OS industry is also undergoing revolutionary changes to take advantage of the potential
offered by the trends in processor technologies. Today we have lot of options to select from a bunch
of commercial and open source embedded OSs for building embedded devices. Most of the embed-
ded OSs are trying to bring the virtualisation concept to the embedded device industry by adopting the
micro kernel architecture in place of the monolithic architecture. In microkemel architecture, the kernel
contains very limited and essential features/services and rest of the features. or services are installed as
service and they run at the user space. Another noticeable trend adopting by OS suppliers is the 'Device
oriented' design similar to the processor trends. In the olden days for building a device, we have to se-
lect an OS matching the device requirements and then customise it. Today OS suppliers are providing
off-the-shelf OS customised for the device. Microsoft Embedded OS product line is a typical example
of this, Microsoft has a range of OSs targeted for a group of device families like point of sale terminal,
media player, set top box, etc. The Windows Mobile OS from Microsoft is specifically designed for
mobile handsets. Open source embedded OS (Mostly centered around Embedded Linux) are gaining
attention in_ the embedded market and the open source community is also offering off the shelf OS cus-
tomised for specific group/family of devices. The Ubuntu MID edition which is specifically designed for
Mobile Internet Device (MID) is a typical example for this. Since the processor technology is shifting
the paradigm of computing from single core to multicore processors, the OS suppliers are also forced
1
to change their strategies for supporting multicore processors. The latest version of the VxWorks (Vx-
1Works 6.6SMPt) RTOS is designed to support the latest market-leading multicore processors.

When we talk about languages for embedded development, there are two aspects. One is the system side
application (embedded device platform development) and the otherpne is the user application develop-
ment. The system side application is responsible for managing the embedded device, interacting with
low level hardware, scheduling and executing user applications, memory management, etc. whereas the
user application runs on top of the system applications and requires the intervention of system applica-
tion for performing system resource access (Like hardware access, memory access, etc.). In Embedded
terminology the system side applications are referred as 'Embedded Firmware' and the user applica-
tions are known as 'Embedded Software'. The embedded firmware always comes as embedded into the
program memory of the device and it is unalterable by the end user. Embedded software comes as either
embedded with the firmware or user can install the software applications later on the device (A typical
example is PDA, where the OS comes as embedded in the device and along with the OS certain applica-
tion software like document viewer, mail client, etc. also .comes as embedded in the device. Users can
download and install rest of the applications in the device).
_Whenever \Ye think of development languages for embedded firmware, the first and foremost
1ai:muage thai comes into our mind is 'C'. The reason being historic, the flexibility provided by 'C'
At the time of writing this book (Year 2008-09).
 Trends in the Embedded Industry

language in hardware access and the bunch of cross-compilers and IDEs available for different plat-
forms. We lived in an era where imagining a language beyond 'C' and Assembly (ALP) for embedded
firmware was impossible. Now the scenario is totally changed. We have object-oriented languages like
C++ for embedded firmware development. Efficient cross platform development tools and compilers
from providers like Microsoft® played a significant role in this transformation. Advances in the com-
piler impleme:Q.tations and processor support brings java as one of the emerging language for system
software development. Though java lacks lot of features essential for system software development, a
move towards improving the missing factors is in progress. Still it is in the infancy stage. We will dis-
cuss the java based development under a separate thread. When it comes to embedded software develop··
ment, a bunch oflanguages, including 'C', 'C++', Microsoft C#, ;(SP.NET, VB, Java,.etc. are available.
The following sections illustrate the role of Java and Microsoft .NET framework supported languages
for embedded development.

16.3.1 Java for Embedded Development

Java being considered as the popular language for enterprise applications due to its platform indepen-
dent implementations, but when it comes to embedded application development (firmware and soft-
ware), it is not so popular due to its inherent shortcomings in real time system development support. In
a basic java development, the java code is compiled by a java class compiler to platfqrm independent
code calledjava bytecode. Thejava bytecode is converted into processor specific object code by a utility
called Java Virtual Machine (NM). JVM abstracts the processor dependency from Java applications.
JVM pei:forms the operation of converting the bytecode into the processor specific machine code imple-
mentations. During run time, the bytecode is interpreted by the JVM for execution. The interpretation
technique makes java applications slower than the other (cross) compiled applications. JVM can be
implemented as either a piece of software code or hardware unit. Nowadays processors are providing
built-in support for Java bytecode execution. The ARM processor implements hardware NM called
jazelle for supporting java. Figure 16.1 given below illustrates the implementation of Java applications
in an embedded device with Operating System.

( Fig. I 6. 1) Java based embedded application develop~ent

As mentioned earlier, NM interprets the bytecode and thereby greatly affects the speed of execution.
Another technique called Just In Time (JIT) compiler speeds up the Java program execution by cach-
ing all the previously interpreted bytecode. This avoids the delay in interpreting a bytecode which was
already interpreted earlier.
 Introduction to Embedded Systems

The limitations of standard Java in embedded application development are:

1. The interpreted version of Java is quite slower and is not meeting the real-time requirement
demanding by most embedded systems (For real-time applications)
2. The garbage collector of Java is non-deterministic in execution behaviour. It is not acceptable for
a hard real-time system.
3. Processors which don't have a built-in JVM support or an off-the-shelf software JVM, require the
JVM ported for the processor architecture.
4. The resource access (Hardware registers, memory, etc.) supported by Java is limited.
5. The runtime memory requirement for JVM and Java class libraries or llT is a bit high and embed-
ded systems which are constrained on memory cannot afford this.
Some movements to overcome these limitations are in the process and lot of novel ideas are emerging
out to ·make Java suitable for embedded applications. The Ahead-of-Time (AOT) compilers for Java is
intended for converting the Java bytecodes to target processor specific assembly code during compile
time. It eliminates the need for a JVM/llT for executing Java code. However there should be a piece
of code for implementing the garbage collection in place of JVM/JIT. AOT compiler also brings the
advantage of linking the compiled bytecode with other modules developed in languages like CIC++ and
Assembly.
Java provides an interface named Java Native Interface (JNI), which can be used for invoking the
functions written in other languages like C and Assembly. The JNI feature of Java can be explored for
implementing system software like, user mode device drivers which has access to the JVM. Since JVM
runs on top of the OS, device drivers which are statically linked with the OS kernel during OS image
building or drivers which are loaded as shared object cannot be implemented using Java. In the Java
based drivers, the low level hardware access is implemented in native languages like C.
The Java Community Process within the Safety Critical Java Technology expert group has come up
with a real-time version for the JVM which is capable of providing comparable execution speed with C
and also with predictable latency and reduced memory footprint.
Java Platform Micro Edition (Java ME), which was known as J2ME earlier, is a customised Java
version specifically designed for 'Embedded application software' development for devices like mobile
phones, PDAs, Set Top Boxes, printers, etc. Java ME applications are portable across devices. Java
ME provides flexible User Interface (UI), built-in network protocols, security, etc. Sun Microsystems
has also released an Embedded version of the Java Standard Edition (Java SE) with optimised memory
footprint requirements for 'embedded application software' development. The embedded edition of the
Java SE supports multicore processors.

16.3.2 .NET CF for Embedded Development

.NET is a framework for application development for desktop Windows Operating Systems (The UNIX
version is also under development) from Microsoft®. It is a collection of pre-coded· libraries and it
acts as the run time componentfor .NET supported languages (C++, C#, VB, J#, etc.). It contains class
libraries for User Interface, database connectivity, network connectivity, image editing, ·cryptography
etc. The runtime environment of .NET is known as Common Language Runtime (CLR). The CLR re-
sembles JVM in operation. It abstracts the target processor from application programmer. 'Like JVM,
CLR also provides memory management (garbage collection), exception handling, etc. The CLR pro-
vides a language neutral platform for application 'development and execution. Applications written in
.NET supported languages are compiled to a platform neutral intermediate language called Common
Intermediate Language (CIL). For actual execution, the CIL is converted to the target processor specific
 Trends in the Embedded Industry

machine code by the Common Language Runtime (CLR). Fig.

16.2 illustrates the concept of .NET framework based program
execution.
The .NET framework is targeted for enterprise application de-
velopment for desktop systems. The .NET framework consumes
significant amount of memory. When it comes to embedded ap- ·
plication development, the .NET framework is not a viable choice
due to its memory requirement. For embedded and small de-
vices running on Microsoft Embedded Operating Systems (like
Windows Mobile and Windows CE), Microsoft® is providing
a stripped down customised version of .NET framework called
.NET Compact Framework or simply .NET CF for application
development. Obviously .NET CF doesn't support all features of
the .NET Framework. But it supports all necessary components Target processor specific
required for application development for small devices. Users can machine code
develop applications in any .NET supported language including
C++, C#, VB, J# etc.

Certain areas of the embedded industry are highly 'hot' and competitive. It ·demands strategic alliances
to sustain in the market and bring innovations through combined R&D. A typical example is the handset
industry. The combined R&D helps hardware manufacturers to come up with new designs and software
developers to support the new hardware. With diverse market players it is essential to have formal
specifications to ensure interoperability in operations. The Open Alliances and standards body are aimed
towards defining and formulating the standards. Time to market is a critical factor in the sensational
embedded market segments. Open sources and frameworks reduce the time to market in product de-
velopment. The following sections highlight the popular strategic alliances, open source standards and
frameworks in the mobile handset industry.

16.4.1 Open Mobile Alliance (OMA)

The Open Mobile Alliance (OMA) is a standards body for developing open standards for mobile phone
industry. The OMA alliance was formed in 2Q02 by stakeholders from the world's leading network op-•
erators, device manufacturers, Information technology companies and content providers. The mission
of OMA is 'To create interoperable services across countries, operators and mobile terminals by acting
as the centre of the mobile service enabler specification work'. Please visit http://v,rww.openmobileal-
liance.org/ for more details on OMA.

16.4.2 Open Handset Alliance (OHA)

The Open Handset Alliance (OHA) is a business alHance formed by various handset manufacturers
(HTC, Samsung, LG, Motorola etc), chip manufacturers (Intel, Nvidia, Qualcomm, etc.), platform-pro-
viders (Google, Wind River Systems, etc.) fnd carriers (T-Mobile, China Mobile, Sprint Nextel, etc.)
for developing standards for mobile devices. Please visit http://www.openhandsetalliance.com/ for more
details on OHA.
 Introduction to Embedded Systems

16.4.3 Android
Android is an open source software platform and operating system for mobile devices. It was developed
by Google Corporation (www.google.com) and retained by the Open Handset Alliance (OH.A). The
Android operating system is based on the Linux kernel. Google has developed a set of Java libraries
and developers can make use of these libraries for application development injava. For more details on
android, please visit the website http://www.android.com/

16.4.4 Openmoko
Openmoko is a project for building open hardware and firmware (OS) standards for a family of open
source mobile phones. The target operating system under consideration by openmoko is Embedded
Linux and it is known as Openmoko Linux. It also supplies the hardware details (schematics and CAD
drawings) of the phone as reference design for developers. Developers can customise the software stack
and hardware to suit their product needs. For more details on Openmoko, please visit the website http://
wiki.openmoko.or.g/wiki/Main Page

So far we discussed about the positives of the embedded technology. Now let's have a look at the bottle-
necks faced by the embedded industry today.

16. 5 .1 Memory Performance

Memory performance is a real road blocker in embedded development. Though processor technologies
are supporting high speed operations through increased clock, the current memory technology is not
yet up to the mark to catch up the speed offered by processors. It is high time to think about alternate
memory techniques that can at least offer a performance somewhat near to that of processors.

16.5.2 La.ck of Standards/Conformance to Standards

Though we talk aboµt various alliances and open standards for specific areas of embedded system, there
are no specific standards in place to ensure interoperability in all areas of embedded development. Even
though, standards are in place for certain areas of the embedded development like mobile handset mar-
ket, only a minor proportion of the players are sticking on to these standards and majority of the players
are still sticking on to their owrt proprietary architecture and designs. To bring innovations and cutting
edge feature rich products, it is essential to have a combined effort and standardisation. It is high time
to think about strategic alliances in all areas of embedded development.

16.5.3 Lack of Skilled Resources

This is the most crucial problem faced by the embedded industry today. 'Design of Embedded System
is an Art' and it requires highly skilled, self motivated and talented people to meet the time criUcalities
.of embedded product development. Though most of our engineering graduates are highly talented, they
lack proper orientation towards the design and development of embedded systems. Lack of good books
on the embedded fundamentals is also a major reason for it. It is high time to think about teaching em-
bedded system as a special branch of undergraduate course in all major universities.
PIC® is a popular 8/16/32 bit RISC microcontroller family from Microchip Technology (www.microchip.com). The 8bit
PIC family comprises the products PICl0F, PIC12F, PIC16F and PIC18F. They differ in the amount of program memory
supported, performance, instruction length and pin count. Based on the architecture, the 8bit PIC family is grouped into
three namely;
Baseline Products based on the original PIC architecture. Tl}-ey suppo1t 12bit instruction set with very limited fea-
tures. They are available in 6 to 40 pin packages. The 6 pin l0F series, some 12F series (8 pin 12F629) and some 16F
series (The 20-pin l 6F690 and 40-pin l 6F887) falls under this category.
Mid-Range This is an extension to the baseline architecture with added features like support for interrupts, on-chip
peripherals (Like AL.Ilconverter, Serial Interfaces, LCD interface, etc.), increased memory, etc. The instruction set for
this architecture is 14bit wide. They are available in 8 to 64 pin packages with operating voltage in the range l.8V to
5.5V. Some products of the 12F (The 8 pin 12F629) and the l 6F (20-pin 16F690 and 40-pin 16F887) series comes under
this category.
High Performance The PIC l 8F J and K series comes under this category. The memory density for these devices
is very high (Up to 128KB program memory and 4KB data memory). They provide built-in support for advanced periph-
erals and communication interfaces like USB, CAN, ·etc. The instmction set for this architecture is 16bit wide. They are
capable of delivering a speed of 16MIPS.
As mentioned earlier we have a bunch of devices to select for our design, from the PIC 8bit family. Some of them have
limited set of I/0 capabilities, on-chip Peripherals, data memory (SRAM) and program memory (FLASH) targeting low
a
end applications. The l 2F508 controller is typical example for this. It contains 512 x 12 bits of program memory, 25
bytes of RAM, 6 I/0 lines and comes in an 8~pin package. On the other hand some of the PIC family devices are feature
rich with a bunch of on-chip peripherals (Like ADC, UART, I2C, SPI, etc.), higher data and program storage memory,
targeting high end applications. The l 6F877 controller is a typieal example for this. It contains 8192 x 14 bits of FLASH
program memory, 368 bytes of RAM, 256 bytes ofEEPROM, 33 UO lines, On-chip peripherals like 10-bitA/D converter,
3-Timer units, USART, Intem1pt Controller, etc. It comes in a 40-pin package.
Here, the 16F877 device is selected as the candidate for illustrating the generic PIC architecture. Figure Al .1 illus-
. trates the architectural details of PIC 16F877 device.
The 16F877 PIC family devices contain three types of memory namely; FLASH memoi-y for storing program code,
data memm-y for storing data and holding registers and EEPROM for holding non-volatile data. PIC follows the Harvard
architecture and thereby contains two separate buses for program memory and data mem01-y fetching. The data bus is
8bit wide and program memory bus is 14bit wide. The Program Counter is 13bit wide and is capable of addressing 8K
 Introduction to Embedded Systems

RAOtoRA5 RBOto RB? RCO to RC7 RDOto RD7 REOto RE2

MCLRi
Vee
vss

(Fig.AU)

program memory locations. The On-chip FLASH memory is partitioned into pages of size 2K bytes each. The program
counter is formed by two register, an 8bit register PCL and a 5bit register PCH. PCL is a read/writable register whereas
PCH is not directly accessible. PCH can be written indirectly through the register PCLATH. A write to the PCLATH
register copies the least significant 5 bits to PCH. The W register holds the resuH of ah operation performed in the ALU.
The data memory contains the general purpose and special function registers and it is partitioned into multiple banks.
Each bank contains 128 bytes. The special function registers are located at the lower memory address area of each bank.
The working RAM is implemented as general purpose registers. The data memory bank is selected by setting the memory
bank selector bits RPI and RPO in the STATUS register. The RPO, RP I combinations for selecting different ~ata memory
banks is given in the following table.
 Overview of PIC and AVR Family of Microcontrollers and ARM Processors

General purpose registers are the memoiy locations available to users for data storage. They can be accessed directly
or indirectly through the File Select Register (FSR). Special Function Registers are used by the CPU and peripherals for
configuration, status indication, data association, etc. They are located in the lower memoiy area of a memoiy bank. The
size of the SFR memoiy varies across device families and the typical size for 16F877 is 96 bytes. The status of arithmetic
operations and reset along with the data memoiy bank selector bits RPO and RPI are held in the STATUS register. The
bit details of the status register is explained below.

The table given below explains the meaning and use of each bit.

The stack of 16F877 is an 8 level deep 13bit wide hardware stack. The stack pointer register which holds the current
address of the stack is not readable and writeable. The stack space for PIC is an independent implementation and it is not
part of either data memoiy or program memoiy. The program counter PC is PUSHed to the stack on execution of a CALL
instruction or when an Interrupt is occurred. The Program Counter is POPed on the execution of a Return instruction
(RETURN or RETLW or RETFIE). The stack operates as a circular queue. When all the 8 locations are PUSHed, a 9th
PUSH operation stores the pushed data at the start of the stack.
The indirect addressing of data memoiy is accomplished by the registers INDF and File Select Register (FSR). INDF
is a virtual register. Any instructions using the INDF register internally accesses the FSR register. In indirect addressing
the memoiy bank is indicated by the IRP bit of the STATUS register and the ih bit (In 0 to 7 numbering) of FSR. The
memory location within the memoiy bank is pointed by the bits 0 to 6 ofFSR register.
l 6F877 contains five bi-directional ports namely; PORTA, PORTB, PORTC, PORTD and PORTE. Ports B, C and D
are 8bit wide, whereas Port A is 6bit wide and Port E is 3bit wide. Each Port associates a data direction register called
TRISx (x== A for PORTA, B for PORTB, C for PORTC, D for PORTD and E for PORTE). It sets the Input or Output
mode for the port. If the TRISx.n bit (where 'n' is the port pin number, 0 to 5 for Port A, 0 to 7 for Port B, C and D, and 0
to 2 for Port E) is set, the corresponding port pin configures as Input Port. PORTx (x =A or B or C or D or E) is the data
register associated with each port. Some of the ports have alternate functions associated with them. The alternate func-
tions are enabled by setting the corresponding bit in the register controlling the alternate functions for a Port. It should
be noted that TRISx is the register deciding I/0 _direction even when the port is operating in the alternate function mode.
The number of ports available in a device is device family specific.
The PIC l 6F877 supports 14 interrupt sources. The interrupt control register INTCON holds the global and individual
interrupt enable bits and bits for recording the status of all interrupts. ,16F877 supports only one Interrupt vector for
I
 Introduction to Embedded Systems

servicing all the interrupts. The interrupt vector is located at code memory location 0004H. The trigger type for external
interrupts can be configured as either rising edge or falling edge, in the OPTION_REG by setting or clearing the INTEDG
flag respectively. RETFIE is the instruction for returning from an interrupt service routine.
A w~tchdog timer is implemented to keep track of the proper execution of instructions. The watchdog timer is imple-
mented as a free running RC oscillator. Watchdog timer doesn't require an external clock for _its operation. During normal
operation, a watchdog timeout resets the controller, whereas if the device is in the SLEEP mode, the watchdog timeout
wakes up the CPU and put the controller in the normal operation mode. The watchdog timer can be enabled or disabled
by setting or clearing the WDTE bit of the CONFIGURATION WORD register.
The l 6F877 device undergoes reset if any one of the following conditions is met:
Power on Reset (FOR) The power on reset signal is generated internally when the voltage supply to the device
reaches in the range 1.2V to 1. 7V when it is raised from 0V. In order to ensure a proper voltage level and stabilised clock,
for proper operation of the device, some delays are introduced upon the detection of a POR. The Power up Timer (PWRT)
is started on detecting a POR. PWRT runs for a period of 72 ms allowing the supply voltage to stabilise. When PWRT
- expires, the Oscillator Start-up Timer (OST) is started when PWRTs time delay expires. OST provides a delay of 1024
oscillator periods. This ensures that the crystal resonator for the oscillator circuit is properly stabilised before the code
execution begins.
Brown-out Reset (BOR) BOR ensures that the program execution flow is not corrupted when the supply voltage
falls below the threshold value for proper operation of the device. Whenever the supply voltage falls below this thresh-
old, the BOR holds the device under reset till the voltage raises above the threshold value. The Brown-out Reset can be
enabled by setting the bit BODEN. Brown-out reset follows the same sequence of operation for PWRT and OST as in the
case of the Power on Reset
Watchdog Reset Watchdog reset occurs when the watchdog timer overflows (if the watchdog timer is in the
enabled state). Watchdog reset can happen either in the normal operation mode or when the controller is in the SLEEP
mode. During normal operation, a watchdog timeout resets the controller., whereas if the device is in the SLEEP mode, the
watchdog timeout wakes up the CPU and put the controller in the normal operation mode. The Watchdog reset in the nor-
mal operation mode follows the same sequence of operation for PWRT and OST as in the case of the Power on Reset.
External Reset The controller can be brought into the reset state at any time during program execution by applying
a reset pulse at the RESET pin (MCLR\). Similar to watchdog timer reset, external reset can happen either in the normal
operation mode or when the controller is in the SLEEP mode. During normal operation, the external reset assertion resets
the controller, whereas if the device is in the SLEEP mode, the external reset wakes up the CPU and put the controller in
the normal operation mode. The external reset in the normal operation mode follows the same sequence of operation for
PWRT and OST as in the case of the Power on Reset.
PIC microcontrollers support power saving, by executing the SLEEP instruction. During SLEEP inode, the watchdog
timer can be kept either in the enabled or disabled. If the watchdog timer is in the enabled state, the controller resumes its
operation when the watchdog timer expires. During SLEEP mode, the 1/0 pins maintain their status at the time of entering
the SLEEP state. The device is wakeup from the SLEEP mode by one of the following events.
1. An external reset signal at pin MCLR\
2. Watchdog timer expiration
3. Occurrence of external Interrupts, port change interrupt or peripheral interrupt
l 6F877 contains three timers/counters namely Timer 0, 1 and 2. Timer 0 can act as an 8bit timer/counter with internal
or external clock. Timer 0 interrupt is generated when the timer count rolls over to OOH from FFH. Timer 0 mode can be
selected by the TOCS bit of the OPTION_REG register. In the timer mode, Timer Oincrements on every instruction cycle
(If the timer pre-scaler is not set). Timer 1 is a 16bit timer/counter (TMRl) consisting of two 8bit registers (TMRlH and
TMRl L). Timer 1 can function as either a timer or counter. In counter mode, timer 1 counts the external pulses occurring
at the corresponding 1/0 pin. Timer 2 is an 8bit timer which is specially designed for generating Pulse Width Modulation
(PWM) signals. Timer 2,generates the PWM time base for Capture Compare PWM module (CCP) 1 and 2. Timer 2 as-
sociates a prescaler and a postscaler.
The Capture Compare PWM Modules (CCP) are associated with PWM sigml gen:::ration and each CCP module· con-
tains a 16bit register which acts as either 16bit capture register or 16bit compare register or 16bit PWM master/slave duty
cycle register.
 Overview of PIC and AVR Family of Microcontrollers and ARM Processors

The Parallel Slave Port (PSP) acts as a slave port which can be directly interfaced tci the 8bit data bus of an external
microprocessor/controller. Port D operates as the Parallel Slave Port. In PSP mode, the external microprocessor can read
or write the PORTD latch.
The Universal Synchronous Asynchronous Receiver Transmitter (USART) acts as the serial communication interface
(SCI) for the device. It supports full duplex asynchronous serial data transfer and half duplex synchronous serial data
transfer. In synchronous half duplex communication, the USART can act as either master or slave. The baudrate for serial
data cm;nmunication is configurable.
Master Synchronous Serial Port (MSSP) or Synchronous Serial Port (SSP) is another serial interface supported by the
l 6F877 device. MSSP can operate as either Serial Peripheral Interface (SPI) or Inter Integrated Circuit (I2C) interface.
The SPI mode requires minimum 3 wires and I2C requires minimum 2 wires for com~unication.
The 16F877 family device contains an on-chip Analog to Digital Converter ADC for analog signal conversion. The
resolution of the ADC is 1Obit. The ADC is contr91led by the ADC register ADCON0 a11d the register ADCCON 1 con-
figures the port pin used for supplying Analog input signal.
PIC 24 and dsPIC series are the 16bit PIC microcontrollers and PIC32 is the 32bit PIC microcontroller frQm micro-
chip. MP LAB from Microchip Technologies is the Integrated Development Environment for the PIC family of microcon-
trollers.

AVR® 8bit RISC is a popular high performance low power 8bit RISC microcontroller family from Atmel (www.atmel.
com). AVR microcontrollers operate at voltages ranging from l.8V to 5:5V and execute instructions in a single clock
cycle. They contain on-chip FLASH memory, EEPROM, SDRAM and built-in peripherals like ADC. The various micro-
controller products coming under the AVR family of umbrella are listed below.
tinyAVR® Smallest version of 8bit AVR microcontroller, Limited pin counts. It contains up to 8K bytes of internal
FLASH program memory and 512 bytes of SRAM and EEPROM. The tinyAVR® microcontrollers are commonly used
for general purpose applications. ·
megaAVR® High performance AVR microcontroller with hardware multiplier. It contains up to 256K bytes of in-
ternal FLASH program memory and 8K bytes of SRAM and 4K bytes of EEPROM.
XMEGA™ High performance AVR microcontrollers with advanced peripherals like DMA and event systems.
AVR microcontrollers are also available as application oriented controllers specifically designed for certain applica-
tions like Automotive (Automotive AVR), CAN networking (CAN AVR), LCD driver (LCD AVR), Motor control, light-
ing applications (Lighting AVR), ZigBee, Remote Access Contr-ol, USB connectivity, etc. The AVR microcontroller may
contain built-in peripherals like ADC, UART, SPI bus interface, etc. Figure A1.3 illustrates the architecture of the AVR
ATmega8 Microcontroller.
The AVR 8 CPU contains an 8bitALU, 32, 8bit general purpose registers, Stack pointer, program counter, instruction
register, instrnction decoder, and status and control register.
AVR follows the 'Harvard' architecture and supports separate memories and buses for program and data. AVR imple-
ments single level 'pipelining' with pre-fetching of instrnction while an instrnction is being executed.
All the 32 registers are directly connected to the ALU and it allows the accessing of two independent registers in one
single instruction execution. The register access time is one clock cycle. Out of the 32 registers, 6 can be used as three
16bit indirect address registers. These 16bit registers are known as 'X', 'Y' and 'Z' registers. The address map of the
general purpose registers are shown below in Fig. Al.2.
The higher 6 registers can be grouped into three 16bit registers as shown.in the register map. Registers R26 and R27
forms the X register with lower order byte of X register in R26. Similarly registers R28 and R29 forms the Y register
with lower order byte of Y register in R28. Register Z is fom1ed by registers R30 and R31 with the lower order byte of Z
register in R30. These registers are used as indirect a,ddressing registers in data memory access and lookup table access
registers for FLASH memory. .
The Sti1ck pointer register is a 16bit register holding the current address of the stack. For AVR architecture, the stack
memory grows down (F:rom a highest memory address to lower address). The stack is implemented in the SRAM mem-
ory area and the stack pointer points to the current location of the stack in the SRAM. The reset value or stack pointer is
 Introduction to Embedded Systems

Z register high byte 0xlF

Z register low byte 0xlE
Y register high byte 0xlD
Y register low byte 0xlC
X register high byte 0xlB
X register low byte 0xlA
0xl9

0xl0
0x0F

0x0I
0x00

Register name Address

0000H. It should be initialised to a value higher than 0060H for proper functioning. Whenever a data byte is 'PUSHed'
to the stack, the stack pointer register is decremented by one. Whenever a data byte is 'POPed' from the stack, the stack
pointer register is incremented by one. This is contradictory with the 8051 stack operation where the stack is located at
the lowest address and it grows up. The stack pointer register is implemented as a combination of two eight bit registers
namely Stack Pointer High (SPH) and Stack Pointer Low (SPL). Both the registers are required only if the size of the
SRAM is greater than 256 bytes. For AVR processors with SRAM less than 256 bytes only the SPL register is physically
implemented see Fig. A 1.3.
The status register SREG holds the status of the most recently executed arithmetic instruction in the ALU. The bit
details of the status register is explained below.

The table given below explains the meaning and use of each bit.
 Overview of PIC and AVR Family of Microcontrollers and ARM Processors

PAO to PA7 PBO to PB7 PCO to PC7 PDOto PD7

AVRCPU

AYR supports a number of interrupts mcl uding AYR CPU specific and additional On-chip hardware specific (These
are implemented only if the microcontroller integrates the hardware in it Examples are SPI intem1pt). The table given
_g,elow summarises the various interrupts supported by ATmega8 and their interrupt vectors.

·('Interrupt Name ,-: ··' '5f\::;;Explanation

tt·;: ,. , ~·r· t?_~:f:J:f_:_t.::~i·:?-
t{ .. . ...

··-i.·.-.l::_~-t~
.· ::.
:.~.... . _.
....·.·.·.·.,.:, ,~;•·•,· ',,,'. ooo··.~•.oo
,:i.•.~.- ·.~.:.l,.·.~.·.·.· ·.·.~:·. :. .:.:.:'· :,.,'..•-.-
. •.
. _tL.•:""'!'!1"_~'.':°'·:•.
·-,r-.·.·.3-.~;
.• :·,·.,.~.~ ;_,_r,. '.·, .' :.;•. ~.-· , ;_·:··_,·IN~TSOET
-.···'""
••·•. . Microcontroller Reset c)c~f. ' :,·
.,.,,, -~•t•·.;-.,r.'EJcterna Int~W1P,!!~i}~{::~~~¥~~-.:
r , '. ' •

<f;' ),
~:;'.f".!. :)-:t."•
0002H INTl .. · 'External Interrupt l ·...·..... ··./.'.: ..:_ ... ·;._.. );;'_'..
' ·...· ..·
.~:::::)fil:,./}~dl*~:f:~•,,.~TIMER2 COMP0~:fJ;~~~~imer/C&unte1-!-~::?
 Introduction to Embedded Systems

,0O04H TIMER2OVF Timer/Counter 2 overflow flag

If the BOOTRST fuse of the AVR microcohtroller is programmed, the reset vector is shifted to the bootloader start
address. The interrupt vector address can be relocated to the start of the bootloader FLASH memory by setting the inter-
rupt vector select (IVSEL) bit of the Interrupt Control register GICR. The reset address and the Interrupt vector address
for the various combinations of interrupt vector select (IVSEL) and BOOTRST and the corresponding reset address and
interrupt vector location are listed in the table given below.

The bit details of the general interrupt control register GICR is explained below.

B7 B.1 ·-,BO·
INTI INTO RSD RSD RSD RSD IVSEL IVCE
As mentioned earlier, the bit IVS EL controls the relocation of Interrupt vector addresses to the bootloader area of
FLASH memo1y. The Interrupt Vector Change Enable enables the relocating of interrupt vectors. In order to enable the
intem1pt relocation, the following sequence of operation should be performed on JVCE & IVSEL.
1. Set IVCE •
2. Within 4 machine cycles of setting JVCE, write the desired value to IVSEL ( I for inte1n1pt vector relocation en-
abling and Ofor disabling interrupt vector relocation) along with a value of Ofor lVCE flag.
Interrupts are automatically disabled during the setting up of IVCE and for 4 machine cycles following the instruc-
tion setting up JVCE. lfIVSEL is not modified within this 4 machine cycles, interrupts are automatically re-enabled. The
global interrupt enabler bit in the status register SREG remains unchanged.
The reset of AYR can happen in four ways. They are:
l . Power ON Reset: The microcontroller is reset when the supply voltage is below the Power ON Reset threshold
value
2. External Reset: The reset pin of the microcontroller is held low for a specified period.
3. Wcrcl1dog Reset: The watchdog Timer is expired. It happens due to flaws in program execution.
4. Brown Out Reset: The supply voltage to the microcontrol\er falls below a specified threshold. This is essential for
preventing data corruptions and unexpected program execution.
 Overview of PIC and AVR Family of Microcontrollers and ARM Processors

During reset, all I/O registers are set to their initial values; all p01ts are reset to their initial states. When the reset
sources go inactive, a delay counter is started to wait for a specified period set by the CKSEL fuses of the device. It
ensures the proper stabilisation of the power source before the start of program execution. The program execution starts
at either the rest vector (0000H) or the Reset address of Boot FLASH depending on the configuration of the BOOTRST
fuse. The MCU Control and Status Register MCUCSR keep track of the source ofreset. The bit details of this register are
shown below.

WDRF is the flag corresponding to a watchdog initiated reset and BORF flag indicates a reset triggered by Brown Out
detection (The operating voltage goes beyond a threshold). If the reset is initiated by the external RESET line, the EXTRF
flag is set. A power On reset sets the PORF flag.
Watchdog timer is a mechanism to bring the controller out of a system hang-up condition. Unexpected program flow
may result in unexpected behaviour and thereby leading to an illusion of total system hang-up. This can be prevented by
using a watchdog timer to monitor the time taken to execute the code segment, which is prone to create system hang-up
behaviour.
The AVR watchdog timer unit contains a built in watchdog timer oscillator which runs at a separate on-chip oscillator
at a frequency of 1MHz. The watchdog reset interval can be adjusted by changing the pre-scaler values of the watchdog
timer. The watchdog timeout event triggers a reset when the watchdog timer exceeds the time period set. The Watchdog
Timer Control Register (WDTCR) controls the operation of the watchdog timer. The bit details of the watchdog timer
register are given below.

The bits, WDP0, WDPl and WDP2 set the oscillator cycles in which the watchdog timer expires (sets the watchdog
timer pre-scaler). It varies from 16K oscillator cycles (WDP0, WDPl, WDP2 000) to 2048K oscillator cycles (WDP0,
WDPI, WDP2 =111). The bit WDE controls the enabling and disabling the watchdog timer. Setting it to 1 starts the
watchdog timer. The bit, Watchdog Change Enable, controls the disabling of the Watchdog timer. In order to disable a
watchdog timer this bit should be set before clearing the watchdog enable bit WOE. Writing a Oto the Watchdog Enable
bit takes effect only when the WDCE bit is at logic 1. Before starting the watchdog timer, it should be resetted using the
instruction WDR.
Apart from the general purpose registers, AVR holds various status, control and configuration registers for config-
uring, controlling and providing feedback on various operations like Port setting, initialisation, read write, watch dog
timer management, intem1pt management, serial data communication, etc. These registers are known as special function
registers. These registers fall under the I/O space and they are accessed by the I/O access instructions/N and OUT. I/O
Registers within the address range 0x00-0xlF are directly bit accessible using the SB! and CBI instructions. In these reg-
isters, the value of single bits can be checked by using the SBIS and SBIC instructions. If the I/O registers are addressed
as data space using the LD and SD instructions, add 0x20 to these addresses.
The external interrupts INTO and INTl are configurable for either level triggering or edge triggering. This can be
configured by setting or clearing the Interrupt Sense Control bits of the MCU Control Register (MCUCR). The bit details
of this register are shown below.

B7 . , B6 :,#5 .B4 '.~.~\ 130

SE SM2 SMl SMO ISCll ISGIO ISC01 ISCOO
Bits ISC11, ISC10 configures the external interrupt INTI and bits ISC0I, ISC00 configures the external interrupt
INTO. The various settings for the bits ISC l and ISC0 and the COlTesponding intenupt triggering conditions are iisted
below.

t RSD - Reserved for Future Use

 Introduction to Embedded Systems

The AYR mega architecture supports multiple bidirectional ports (Up to 4 Ports: Port A, Port B, Port C and Port D)
with configurable pull-up option. The ports can be configured as either input port or output port. Each port contains a
group of port pins (up to 8 pins). Port pins are internally pulled to logic 'High' using pull-up resistors. All I/0 pins have
protection diodes to bot~ +ve supply voltage and ground. Three 1/0 mapped registers are associated with each port. They
are:
Data Direction Register (DDRx) The data direction register associated with Port x (where x can beA or B or
• C or D). If the bit corresponding to a port pin is set as 1, the port pin is configured as output pin. If the bit is set as 0, the
corresponding pin of the port is configured as input pin. -
Data Register (PORTx) The data register associated with Port x (where x canhe A or B or C or D). It is used for
holding the data to output to the port when it is configured as an Output port. When the Port is configured as 1/p port, the
Data register is used for turning ON and OFF the pull-up resistors associated with each pin of the port.
Port Input Pin (P/Nx) This register holds the Pin status.
Three register bits namely DDxn (bits in (DDRx Register), PORTxn and PINxn (where x = A or B or C or D and n =
0 to 7) are associated with each port pin. The DDxn bit selects the direction of the port. A value of 1 sets the port pin as
Output port and a valueof0 sets the port pin as input port. If PORTxn is set at logic 1 when the DDxn for the correspond-
ing port pin is configured as input pin, the Pull-up associated with the port pin is activated. The pull up associated with
the pin can be turned Off by writing a logic 0 to the corresponding PORT:xn register bit or by setting the Pin as Output
pin. If port pin PORTxn is written with logic 1 when the DDxn pin of it is configured as Output pin, the port pin is driven
'High'. The port pin is driven 'Low' in the output mode by writing a 0 to the PORTxn register bit.
Apart from bi-directional 1/0 operation, some of the port pins support alternate functions. The alternate functions for a
port pin can be enabled by overriding the port pin 1/0 functionality with alternate functions. These overriding is enabled
by setting the override bit corresponding to the alternate function in the corresponding special function register holding
the ove1Tide bit. The override value can be mentioned in the corresponding bit. Hence for each alternate function, two bits
are required; 1 for enabling the override and the other one for setting the override value.
The mega8 AYR supports two 8bit Timers/Counters and a 16bit Timer/Counter. Timer/counter O can operate in any
one of the modes; Single Channel Counter, Frequency Generator, External Event Counter and 10-bit Clock pre-scaler:
The clock to the timer unit is supplied via the internal clock or via a clock prescaler or via an external clock source on
the port pin TO. The Timer/Counter is incremented at each clock tick. The counting happens in the upward direction and
the Timer/Counter register overflows to OOH on next clock pulse when the count value is maximum, i.e. 0FFH. Whenever
a Timer/Counter overflov;r occurs, it is indicated through the flag corresponding to the timer.
Each 8bit timer 'x' (x = 0 or 2) associates the following registers with it for operation
1. A Timer/Counter Control Register (TCCRx) for selecting the clock source
2. A Timer/Counter Register (TCNTx) for holding the count
3. A Timer/Counter Interrupt mask register (TIMSK). It contains the bit TOIEx for individually enabling or disabling
the Tiiner/Counter x interrupt.
4. Timer/Counter Interrupt Flag Register (TIFR). It contains the bit TOYx for indicating the overflow of Timer/Coun-
ter x. His cleared by hardware when the interrupt vectors to its ISR.
The 16bit timer (Timer/Counter 1) serves as Pulse Width Modulation (PWM) generator/Frequency generator and
external event counter.
AVR has a built-in USART for full duplex synchronous or asynchronous serial data communication. It supports Serial
Frames with 5, 6, 7, 8, or 9 data bits and 1 or 2 Stop Bits, with hardware based odd or even parity generation and parity
check. Port D bit 0 and bit 1 when configured in the alternate function mode serves as the Receive Pi.n and Transmit Pin
respectively for serial data communication. The USART Transmitter has two flags namely; USART Data Register Empty
 Overview of PIC and AVR Family of Microcontrollers and ARM Processors

(UDRE) and Transmit Complete (TXC) for indicating its state. The flag UDRE is set when the transmit buffer is ~mpty.
The flag TXC is set upon transmission of data. Both of these flags can be used for generating interrupts. Similarly the
USART receiver has one flag named Receive Complete (RXC) for indicating the availability of data in the receive buf-
fer.
AVR microcontrQller contains a special program called bootloader located in the FLASH memory. It has the capabil-
ity to load program into the FLASH memory area of the controller. It facilitates firmware upgrades. The bootloader is
self modifiable, and it can also erase itself from the code if it is not required anymore. The bootloader memory size is
configurable with fuses and it has two independently configurable boot lock bits for locking the bootloader for security
reasons. The bootloader program can be configured to execute either on .power on reset (If the BOOTRST fuse of the
AVR microcontroller is programmed, the reset vector is shifted to the bootloader stai;t address) or on receiving a specific
command from a host PC through the USART or SPI interface.
The AVR architecture incorporates multiple levels of power saving. The different l~vels correspond to a power sav-
ing mode and the device should put in the corresponding mode to take advantage of the power savings. The power sav-
ing mode is activated by executing the SLEEP instruction. The power saving mode is set in the MCU Cont_rol Register
(MCUCR) before executing the SLEEP instruction. The details of the MCUCR bits associated with power saving is
illustrated below.

The Sleep Enable (SE~it enables the CPU to enter sleep state on executing a SLEEP instruction. Bits SMO, SMl and
SM2 sets the power saving mode. The different power saving modes supported by AVR are listed below.
Idle Mode Thrn mode is set by configuring the bits SM2:SM1 :SM0 as 0:0:0 with SE 1. The clock to CPU is frozen.
CPU stops execution. Other units like SPI, USART, Analog Comparator, ADC, Two-:-wire Serial Interface, Timer/Coun-
ters, Watchdog, and the interrupt system continue operational. The Idle mode is terminated by an externally or internally
triggered interrupt like external interrupts, Timer Overflow and USART Tran_smit Complete interrupts and Analog Com-
parator interrupt, etc.
ADC Noise Reduction Mode This mode is set by configuring the bits SM2:SM1:SMO as 0:0:1 with SE= I.
The clock to I/O system, CPU is frozen. CPU stops execution. Other units like ADC, external interrupts, two-wire Serial
Interface address watch, Timer/Counter2 and the Watchdog timer (if enabled) continue operational. This mode is termi-
nated by an ADC Conversion Complete interrupt, or an External reset, or a Watchdog Reset, or a Brown-out Reset, or a
Two-wire Serial Interface address match interrupt, or a Timer/Counter2 intenupt, or an SPM/EEPROM ready interrupt,
or an external interrupt (INTO or INTI)
Power down Mode This mode is set by configuring the bits SM2:SM1:SM0 as 0:1:0 with SE 1. The external
oscillator is halted and stops all internally generated clocks. All modules using the generated clock are frozen. External
interrupts, Two-wire Serial Interface address watch, and the watchdog continue operational. The power down mode is
terminated by an External Reset, or a Watchdog Reset, or a Brown-out Reset, or a Two-wire Serial Interface address
match interrupt, or an external level interrupt:
Power save Mode This mode is set by configuring the bits SM2:SM1:SM0 as 0:1:l with SE I. This mode is
same as Power down mode except that Timer/Counter 2 continue runs in this mode if it is clocked asynchronously. Along
with the power down mode termination conditions, a TimerOverflow or an Output Compare event from Timer/Counter2
also triggers the termination of this mode.
Standby Mode This mode is set by configuring the bits SM2:SM1:SM0 as 1: I :0 with SE 1 and when the external
clock is used. The device wakes up from the standby mode in 6 clock cycles.
The size of on-chip FLASH memory, SRAM and EEPROM varies across different members of the AVR family. AVR
8 family supports FLASH memory up to 256KB, EEPROM from 64 bytes to 4KB and SRAM up to 8KB. Also the pres-
ence of on-chip peripherals like ADC, Two Wire Interface (TWI), SPI, etc. varies across the family members.
AVR normally does not support the execution of program from external program memory. The code is always ex-
ecuted form the internal FLASH memory.
 Introduction to Embedded Systems

AVR provides built in On-Chip debug support in the fonn of either JTAG interface or DebugWIRE (1-Wire) interface.
All AVR mega family devices with 16KB or more FLASH memory supports built in JTAG interface for On-chip debug-
ging and In System Programming. All new AVR mega family devices with FLASH memory less than 16KB supports the
1-Wire debug interface.
Please refer to the website http://www.atmel.com/dyn/resources/prod documents/doc0856.pdf for details on the In-
struction set for 8bit AVR.
AVR® 32 is a 32bit microcontroller family from Atmel featuring Single Instruction Multiple Data (SIMD) and DSP
instructions. It also supports audio and video processing features.

Advanced RISC Machines (or ARM) is a powerful 32bit RISC processor from ARM Holdings (www.arrn.com). ARM
holdings is a joint venture between Acom Computers (http://www.acomcomputers.co.ukL), Apple Computers (www.
apple.com) and VLSI Technology (www.vlsi.com www.nxp.com) and is founded in 1990. ARM Holdings is the Intel-
lectual Property (IP) supplier of ARM processor core and it doesn't manufacture ARM processor chips. ARM designs
the ARM processor core and licences its ARM IP to their networked partners. The partners can utilise the ARM IP for
building System On Chip devices. Freescale semiconductors, Texas Instruments, NXP (Philips) Semiconductors, etc. are
some of the channel partners of ARM, which fabricates ARM processors. Please visit the ARM website http://www.ann.
com/community/all partners.php for the complete list of ARM community partners.
The ARM architecture has evolved a lot from its first version ARMl to the latest ARMl 1 Processor core. ARMl,
ARM2, ARM3, ARM 4&5, ARM6, ARM7, ARMS, StrongARM, ARM9, ARMl0 and ARMl 1 are the product families
from ARM since its introduction to the market. Some ARM pr(?Cessor extensions like Thumb, EI Segundo, Jazelle, etc.
are also introduced by ARM during its journey from ARMl to ARM! 1.
ARM is a RISC processor and it supports multiple levels of pipelines for instruction execution. ARM contains thirty-
seven 32bit registers. Out of the 37 registers 30 are general purpose registers and 16 general purpose registers (Registers
r0 to rl5) are available in the user mode of operation. Register r15 is the program counter (pc). Register r13 functions as
the stack pointer register (sp). Register rl4 is used as link register (Ir) for the branch and link instructions. The Current
Program Status Register (CPSR) holds execution status of the processor, processor operation mode, interrupt enable bit
status, etc. The details of the bits associated with the CPSR register is illustrated below.

The condition code flags' status reflects the following scenarios:

N = 1: The result of ALU operation is negative
Z l: The result of ALU operation is zero
C I: Ca1ry generated as a result of the operation executed in ALU
V 1: ALU operation resulted in Overflow
The J bit specifies whether the processor is in Jazelle state or not. The T bit indicates whether the ARM is using 32bit
ARM instruction or 16bit Thumb instrnction. The 'I' and 'F' flags are used for disabling Interrupts. If 'I' is set to 1, the
Nonna! interrupts are disabled. Setting 'F' to l disables the Fast Interrupts. The Mode select bits, BO to B4, select the
operating mode for the processor. ARM supports the following operating modes:
User Mode It is the main execution mode for user applications. This mode is also known as 'Unprivileged Mode'.
It enables the protection and isolation of operating system from user applications.
Fast Interrupt Processing (FIQ) Mode The processor enters this mode when a high priority interrupt is
raised.
Normal Interrupt Processing (IRQ) Mode The processor enters this mode when a normal priority inter-
rupt (Interrupts other than high priority) is raised.
 Overview of PIG and AVR Family of Microcontrollers and ARM Processors

Supervisor/Software Interrupt Mode The processor enters this mode on reset and when a software inter-
rupt instruction is executed.
i

Abort Mode Enters this mode when a memory access violation occurs

\ Undefined Instruction Mode Enters this mode when the processor tries to execute an undefined instruction.
System Mode This mode is used for running operating system tasks. It uses the same register as the User mode.
All the above modes, except User mode, are privileged modes. The privileged mode uses several other registers than
the registers available in the user mode..Figure Al .4 illustrates the register organisation for the various modes .

. Supervisor Undef Abort System

User mode FIQmode IRQ mode
mode Mode mode mode

~ supports multiple levels of pipelining for improving the speed of operation. The first generation of ARM pro-
cessors implemented 3-stage pipelining. This pipelining model was followed till ARM7TDMI core. This pipeline model
was based on the classical fetch-decode-execute sequence and it executed one instruction per cycle in the absence of
pipelining. The ARM9 family implements a 5-stage pipelining with separate instruction and data cache. The continuous
improvements over the pipelining model brought a new pipeline architecture, which supports 6-stage pipelining for the
ARMl 0 family of devices. In this model, both the instruction and data buses are 64bit wide and it enabled the fetching
of two instructions on each cycle. The ~ l l family of devices is designed to support 8-stage pipelining. Here the shift
_operation is segregated to a separate pipeline and both instruction and data cache access are distributed across 2 pipeline
_stages.
The Instruction Set Architecture (ISA) of ARM supports three different types of Instruction sets, namely:
ARM Instruction Set The original ARM instruction set. Here all instructions.are 32bit wide and are word aligned.
Since all instructions are word aligned, one single fetch reads four 8bit memory locations. Hence there is no significance
for the lower 2 bits (b0 and bl which generates 4) of the programcounter. Only bits 2 to 31 of PC are significant for ARM
instructions.
Thumb Instruction Set Thumb is the 16bit subset for the 32bit ARM instructions. These instructions can be
·(

'I considered as a 16bit compressed form of the original 32bit ARM instructions. These instructions can be executed either
I
I
by decompressing the instruction to the original 32bitARM instruction or by using a dedicated 16bit Instruction decoding
i. unit. Here all instructions are half word aligned; meaning one single fetch reads two 8bit memory locations. Hence there
~
1
is no significance for the lower bit (b0 which generates 2) of the program counter. Only bits 1 to 31 of PC are significant
i for Thumb instructions. Thumb instructions provide higher code density than the 32bit original ARM instructions. The
concept of thumb instruction was introduced in the ARM V4 (Version 4.0) architecture.

\ Jazelle Instruction Set Jazelle is the hardware implementation of the Java Virtual Machine (NM) for executing
.,.,~java
.
byte codes. The 140 Java instructions are implemented directly in the Jazelle hardware unit, rest 94 Java instructions
 Introduction to Embedded Systems

are implemented by emulating them with multiple ARJvf instructions. All instructions related to the Jazelle are 8bit wide.
Here the processor reads 4 instructions at a time by a word access.
All ARM instructions are conditional, meaning all instructions associate a conditional code with them. The condition
code specifies the condition to be checked (Flags to be tested) for executing the instruction. A typical instruction looks
like Opcode <condition code> Operands, e.g. ADDAL r0,rl,r2 always adds rl and r2 and stores the result in register
rO, whereas the instruction ADDEQ rO,r l ,r2 adds r1 and r2 only if the zero flag (Z) is set. The table given below gives a
snapshot of the different condition codes supported by ARJvf.

Use the condition code AL for executing the instruction regardless of any 1conditions. The ARM instruction set can be
broadly classified into:
Data Processing Instructions The data processing instructions include the arithmetical and logical operation
instructions, comparison and data movement instructions. The following table summarises the data processing operations
supported by ARM.

<:,11eration c,te.g9fY. Instructions

Arithmetic ADD, ADC, SUB, SBC, RSB, RSC
L9~9~l·. ··~~:'.:9~,:~pi\)HC'
Comparisons CMP, C.tvl;N,TST, TEQ.
Data Movement MOV,MVN
These instructions work only on registers. Not on memory.
Single Register and Multiple Register Data transfer Instructions
The instructions related to register data transfer come under this category. These instructions involve either a single reg-
ister data transfer or multiple register data transfer
Program Control (Branching) Instructions Diverts the program flow. It can be either a conditional execu-
tion or unconditional branching. BX, B, BL, etc. are examples for branching instructions.
Multiplication Instructions Multiply (MUL), Multiply Accumulate (MLA), Multiply Long (MLL) and Multi-
ply Long Accmmulate (MLAL) instructions are the multiply instructions supported by ARM Instruction set.
 Overview of PIC and AVR Family of Microcontrollers and ARM Processors

Barrel shift Operations ARM ISA doesn't implement shift instructions by default. However shift operations are
implemented as part of other instructions, with the help of a barrel shifter. Bit shifting operations like Logical Left Shift
(LSL), Arithmetic Right Shift (ASR), Logical Right Shift (LSR), Rotate Right (ROR), and Rotate Right Extended (RRE)
are examples for this,
Branching Instructions For changing the program execution flow. It can be either conditional branching or
unconditional branching.
Co-Processor Specific Instructions ARM does not execute c~rtain instructions and lets a co-processor to
execute these instructions. CDP, LDC, STC, MRC, MCR, etc. are examples for this.
Under ARM architecture, Interrupts, Reset, memory access error, etc. are considered as exceptions and ARM has a
well defined exception mechanism to handle them. The different exceptions defined by ARM are listed below.

ex,~bo..l!l excepl: the 'Reset'', the various operations performed are listed below.
I. Copy the contents of the CPSR register to the SPSR register of the new mode.
2. Set the following states in the CPSR register
(a) Change the state to ARM
(b) Change the mode to exception mode, e.g. FIQ mode for Fast Interrupts.
(c) Disable interrupts if needed
3. Save the address of the instruction following the instruction generated the exception to the register 'rl4' LR (reg-
ister) of the mode corresponding to the exception.
4. Set Program counter with the vector address corresponding to the exception.
Figure A 1.5 given below explains the vector address for all exceptions.

0xlC
Oxl8
0xl4
OxlO
0x0C
Ox08
0x04
OxOO
Vector Table Address
 Introduction to Embedded Systems

Upon the execution completion of the exception code, the following actions are perfonned.
I. Restore CPSR register from the SPSR register of the current mode
2. Restore Program counter from register 'rl4', (LR) of the current mode.
The processor bus architecture followed by ARM is known as Advanced Microcontroller Bus Architecture (AMBA).
The AMBA architecture stanqardises the on-chip connection of different IP cores and enables IP reusability. The AMBA
specifications define three different buses for on-chip device communication. They are:
Advanced High Performance Bus (AHB) AHB acts as the backboneforconnectinghigh-perfonnance, high
clock frequency system modules like memory controliers~ DMA bus master, etc.
Advanced System Bus (ASE) ASB is used for connecting high perfonnance syst~m modules. ASB is an alter-
native system bus for AHB, for system modules which don't requ.ire perfonnance up to the mark offered by ARB.
Advanced Peripheral Bus (APB) APB is a simple, low perfonnance, low power bus used for connecting low
speed peripherals.
ARM supplies the high performance processor core and the specification for the different buses for connecting with
the ARM core. The ARM partners can build System on Chip (SoC) devices by integrating various peripherals to the ARM
core using the AMBA specified bus. A typical SoC architecture using the ARM core and AMBA bus standard is given in
Fig. Al.6.

ARM based mkrocontroller SoC

(Fig.Al.6 J
 Design and Implement a Digital Clock as per the requirements given below.
1. Use a 16 character 2-line display for displaying the current Time. Display the time in DAY HH:MM:SS format
on the first line. Display the message 'Have A Nice Day!' on the second line. DAY represents the day of the Week
(SUN, MON, TUE, WED, THU, FRI and SAT). HH represents the hour in 2 digit fonnat. Depending on the format
settings it may vary from 00 to 12 (12 Hour Format) or from 00 to 23 (24 Hour format). MM represents the minute
in 2 digit format. It varies from 00 to 59. SS represents the seconds in 2 digit format. it varies from 00 to 59. The
alignment of display character should be centre justified (Meaning if the characters to display are 12, pack it with
2 blank space each at right and left and then display).
2. Interface a Hitachi HD44780 compatible LCD with 8051 microcontroller as per-the following interface details
Data Bus: Port P2
Register Select Control.line (RS): Port Pin Pl.4
Read/Write Control Signal (RW): Port Pin Pl .5
.l LCD Enable (E): Pl.6
3. The Backlight of the LCD should be always ON
4. Use AT89C51/52 or AT89S8252 microcontroller. Use a crystal Oscillator with frequency 12.00 MHz.
This will provide accurate timing of 1 microsecond/ma~hine cycle.
5. A 2 x 2 matrix key board (4 keys) is interfaced to Port Pl of the microcontroller. The key details are MENU key
connected to Row 0, and Column 0 of the matrix; ESC key connected to Row 0, and Column 1 of the matrix;
UP key connected to Row 1, and Column 0 of the matrix; DOWN key connected to Row 1, and Column 1 of the
matrix. The Rows 0, 1 and columns 0, 1 of matrix keyboard are interfaced to Port pins Pl.0, Pl.1, Pl.2 and Pl.3
respectively.
6. The hour (HH) and minutes (MM) should be adjustable through a Menu Screen. The Menu screen is invoked by
pressing the MENU key of the matrix key.
7. The selection of an item in the menu is achieved by pressing the MENU key (Performs the Enter Key function).
Exit from the menu is achieved through pressing the ESC key. Pressing the ESC key takes the user to the previous
menu.
8. The menu contains 4 submenu items, namely 'Adjust Hour', 'Adjust Minute', 'Adjust Day' and 'Adjust Format'.
The 'Adjust Hour' adjusts the· hour, 'Adjust Minute' adjusts the minute, 'Adjust Day' adjusts the day.of the week
(SUN to SAT) and 'Adjust Format' adjusts the hour display format (12 hour/24 hour format). 'Adjust Hour' is the
default submenu item and on invoking the menu this prompt is displayed on the screen. The user can select other
menus by pressing the UP or DOWN key. Once the submenu is selected, the User can enter that submenu by press-
\_
 Introduction to Embedded Systems

ing the MENU key. The Submenu lists the current Hour or the Current Minute or the Current Day or the Current
Fonnat according to the submenu selected. User can adjust the values for each by pressing the UP or DOWN key.
Once a value is selected, fr can be applied by pressing the MENU key. Pressing the MENU key applies the new
value and takes the user to the previous menu. Pressing ESC from any point takes the user to the previous menu.
The menu arrangement is illustrated in A2.1.

Main Menu Submenu 1 Submenu2

Adjust Hour Select AM/PM

(0 to 12 or 23
Adjust Hour ~ ~
[AM]
depending on
fonnat settings) [PM]

Adjust Minute ,---------_. Adjust Minute

(00 to 59)

Adjust Day
[SUN]
Adjust Day ~

[SAT]

Adjust Fonnat
Adjust Fonnat ~ [12 Hour]
[24 Hour]

Solution:
The HD44780 standard for LCD defines a unique set of control signals, data bus and command set for Alpha numeric
Liquid Crystal Display (LCD) units. This makes the interfacing and controlling of Alpha numeric LCD unit built using
the Display Controller Hitachi 44780, independent of the LCD manufacturer. As per the HD44780 standard, the LCD
contains 3 controlling signal and a 4 bit/8bit data bus. The 4 bit/8 bit mode of operation is configurable. The Display
modules come in different varieties like single line 8 character, single line 16 character, 2 line 8 character, 2 line 16 char-
acter, etc. The Pin details for an HD44780 compatible, 2 line 16-character LCD module (ODM16112) from ORIOLE
Electronics (www.orioleindia.com) is given in Fig. A2.2.
2 LINE 16 CHARACTER ALPHA NUMERIC LCD

1111111111111111
11111111111'1 I I I I
u
~
"O

~ ---~ z
u
u
u ....:i 0 .-<
("()
N "St" <t) \0 r-- u
0 > ~
> "St" ~ \0 l:.il 0 Q Q Q .-<
0
Q Q Q 0
N ("() "St"
>
<t) \0
..-< N ("() <t) r-- 00 0\ .-< .-< ..-< ..-< ..-< ..-< ..-<
 Design Case Studies

The LCD module contains interface pins for power supply, backlight control, LCD control and data lines. They are
explained below.

Power Supply and Backlight Control Interface

The Power supply and Backlight control interface for the LCD module is tabulated below.

Control and Data Interface

The LCD unit can accept either 4bit data or 8bit data. The data bit width can be set programmatically. There are three
control signals associated with controlling the data/control command exchange with LCD. The control and data bus
signal details are tabulated below.

4 RS Command Register
RS = 1 Selects Data Register
5 ·tR:~f9 •. . f<:?~~\}i:ti:Ht: L<f,,;••
RW ~ l /G,2rritµ~5l R~gis~fRead.
6 EN Enable Signal. Signal for latching the data present on the data bu$ to.the
LCD unit. This signal is active falling edge triggered (1 to Otransition
is required for asserting this signal)
The HD44780 display controller contains an Instruction register and a data register for holding the commands and the
data respectively to the controller. The commands and data to the controller is sent through the same data bus interface.
The RS control signal interface is asse11ed accordingly and the RW signal is asserted low to inform the controller that
the incoming data is command data or display data. For reading from the controller, the RW signal is asserted high and
the RS signal is asserted low or high according to the requirement (RS= 0 for reading the command register. RS= 1 for
reading from the data register).

* lt may vary depending on the LCD module manufacturer.

 Introduction to Embedded Systems

The command register holds the different commands sent by the host controller (8051) CPU to control the various
options of the LCD. We will discuss the various control commands at a later section. For displaying a character on the
LCD, the ASCII value of the character (For example 30H for displaying 0) is written to the data port of LCD. The LCD
module contains two types of memory; nameiy; Display Data RAM (DDR) and Character Generator RAM. Display Data
RAM is the memory which holds the ASCII value of the characters written to the LCD. The display data RAM size for the
ODM16112 module is 80 characters. Each Crystal cell in the LCD module is mapped to the DDRAM location. The first
40 DDRAM address locations (OOH to 27H) are mapped for the crystal cells corresponding to the first line. The next 40
DDRAM memory locations are mapped to the crystal cells for the second line and the address range for these DDRAM
is from 40H to 67H.
The Character Generator RAM (CGRAM) is used for generating and storing user generated character patterns. Read-
ers are requested to go through the LCD module·manual for generating and storing user generated character pattern.
The various parameters for configuring and controlling the LCD is sent as commands to the Instruction register of the
LCD. These parameters include, the interface length setting (4 or 8 bit interface), Display Data Address Selection, LCD
cursor movement, Clear the LCD, display character scrolling, etc. For more details on the supported command set for the
LCD module, refer to the LCD manual. The COtll1110n commands supported for executing the commands for an HD44780
standard LCD module is listed below.

For all the commands listed above, except the Busy flag check, the RS signal is 0 (RS 0 Command Register Selec-
tion) and RW signal is 0 (RW 0 Write to LCD).
For the Busy Flag check instruction, the RS signal is 0 and RW signal is l (Read Operation). The busy flag gives an
indication of whether the system is busy in processing a command. The busy flag (BF) should be checked before writing
a command to the LCD.
For proper operation of the LCD, it should be initialised properly as per the initialisation sequence listed in the LCD
manual. The LCD undergoes an internal power on initialisation following the application of VCC to the LCD module.
During this period the LCD will not accept any external commands. The Initialisation sequence for a standard HD44780
display is illustrated in Fig. A2.3.
Please refer to the datasheet of the LCD module for exact details on the initialisation routine.
Now let us have a look at the matrix keyboard. You can either buy a ready to use 2 x 2 matrix keyboard or can build
own 2 x 2 matrix keyboard using 4 push button switches. The arrangement of push buttons and the interfacing of the
matrix keyboard is shown in Fig. A2.4.
In a matrix keyboard, the keys are arranged in matrix fashion (i.e. they are connected in a row and column style). For
detecting a keypress, the keyboard uses the scanning technique, where each row of the matrix is pulled low and the col-

* Don't Care. It can be either Oor 1

 Design Case Studies

Apply power

Wait for 15 milliseconds

Send function set command
Wait for 5 milliseconds
Send function set command
Wait for 160 microsecqnds
Send function set command
Wait for 160 microseconds

vcc

Send function set command

Read busy flag

YES
MENU ESC

RowO
y y
PLO UP

Row 1 y
.Set entry mode
Pl.1 Clear display
0

~ ] Tum ON display

-u
::l
0 0
u
Set the Display Data RAM address
Set any other parameters required
(Check busy flag after sending each
command)
Pl.2 Pl.3

mnns are read. After reading the status.of each columns corresponding to a row, the row is pulled high and the next row
is pulled low one by one and the status of the columns are read. This process is repeated until the scanning for all rows are
completed. When a row is pulled low and if a key connected to the row is pressed, reading the column to which the key
is connected will give logic 0. Since keys are mechanical devices, there is a possibility for debounce issues, which may
give multiple key press effect for a single keypress. To prevent this, a proper key debouncing technique shoul.d be applied.
Hardware keydebouncer circuits and software keydebounce techniques are the keydebouncing techniques available. The
software keydebouncing techni!e doesn't require any additional hardware and is easy to implement. In tlie software
debouncing technique, on detecti g a keypress, the k~y is read again after a debounce delay. If the keypress is a genuine
one, the state of the key will re ain as 'pressed' on the seconp read also. Pull-up resistors are connected to the column
lines to limit the current that flows to the row line on a keypress.
The necessary hardware interfacing and circuit diagram for implementing the digital clock is given in Fig, A2.5.
The next step is the design of the firmware for implementing the digital clock. Timer Ois used for generating precise
time generation. Timer Owhen configured in the 16bit timer mode can generate precise timing of 65536 (FFFFH + 1)
machine cycles. For a clock frequency of 12MHz, the time for 1 machine cycle is 1 microsecond. Timer Oin 16bit Timer
 1N4007
+
3
<
s·c:,
220MFD/+,,...:::::::=
I
<<
_(j
N
25V -
gR
i-

~ 2 LINE 16 CHARACTER ALPHA NUMERIC LCD

~
r- .r-
s::t= s::t=

ESC MENU 1111111111111111 !::i'

~
N
■ 111111111111111 a
'<DOWN "''< UP 00 0...
i:::

=21: : E~ ~~ d ~ ~
r,

~I iSli[
N ~ ffil 1,j .sl sj s
("f')I V) \0 r:- 00 0-. ~.
;!;
g
0

-
00
"St 0
r-
,..... o
-s:t"Sl-
~
tr
C'l)

§:
~~ C'l)
0...

~
ib"
~

22pF~. 1~
112 ..;,,z l22pF

(Fig.· A2 .5) Circuit diagram for Digital Clock implem~nta'.tio~·:11;~ihg;\11osr

l
Design Case Studies

mode, with a count loaded OOH; generates Timer Interrupt after 65536 machine cycles (i.e. after 65536 microseconds ~
65 milliseconds). For generating a timing of 1 second, timer 0 can be loaded with a count for generating 50 milliseconds.
ATimer multiplier counter can be used to generate 1 second timing:TheTimer multiplier counter is incremented by one
each time the timer 0 rolls over from FFFFH to 0000H. The seconds register is incremented each time when the Timer
multiplier counter becomes1 20. The minutes register is incremented each time when the 'seconds' register become 60.
The hour register is incremented by one each tim~ when the minutes register become 60. The hour is adjusted according
to the hour format, i.e. hour is adjusted in the range 1 to 12 for 12 Hour format and Oto 23 for 24 Hour format. For 24 hour
format, the day register is incremented by one when the hour register' rolls over from 23 to 0. For 12 hour time format the
day register is incremented by one when the hour register rolls over from 12 to 1 and the time format changes from PM
toAM.
Two sets of registers or memory locations for hour, minute, seconds, day, time format and AM/PM selection is used.
The first set of registers is the real registers for representing the time. These r~gisters are modified inside the Timer 0
interrupt in accordance with the seconds, minute, hour, day and AM/PM change. The register details are given below.
R7: Seconds Register
R6: Minute Register
RS: Hour Register
R4: Day Register
Bit 0: Format Register (only l bit is required since format falls into either of (12/24)
Bit 1: AM/PM Register (only 1 bit is required since the time falls into either AM/PM
(The memory location 20H is the physical storage location for bits with address OOH and 0lH)
The ~cond set of registers is used within the menu to adjust these values as and when the user changes it through
menu. Here data memory locations are used for holding the variables. The details of the memory variables are given
below.
30H: Seconds Register
3 lH: Minute Register
32H: Hour Register
33H: Day Register
Bit 2: Format Register (only 1 bit is required since format falls into either of (12/24)
Bit 3: AM/PM Register (only 1 bit is required since the time falls into either AM/PM
(The memory location 20H is the physical storage location for bits with address 02H and 03H)
The LCD'needs to be updated only when there is a change in time or when the user exits frorri'the menu. This is indi-
cated by setting a flag. The flag name is time_changed and it is a bit variable with bit address 04H. The flow chart given
in Fig. A2.6 below models the firmware requirements for building the Digital Clock.
The detection of keypress and the triggering of corresponding action are performed by the 'Key Handler' function
implementation. The key handler scans the rows and columns of the ke_yboard and identifies which key is pressed. On
detecting a keypress the actions corresponding to that key is invoked by the 'Key Handler' function. The keybouncing is
implemented using a 20 milliseconds delay. If a key is found closed during a scan, the same key is read after 20 millisec-
onds to confirm it is a deliberate key closure. Hence a key should be held in pressed condition for at least 20 milliseconds
to identify it as valid key closure input. Otherwise the key closure is considered as an accidental one and it is ignored.
The flow chart given in Fig. A2.7 illustrates the implementation of the 'Key Handler'.
The 'Menu Key Handler' function implements the handling of the 'MENU' key in different contexts. In the nom1al
scenario, the 'MENU' key is used for invoking the 'Main Menu'. Within the 'Menu', the 'MENU' key functions as an
'ENTER' key. The flow chart given in Fig. A2.8 illustrates the implementation of 'MENU' key handling.
The 'Up Key Handler' function implements the handling of the 'UP' key in different contexts. Inside the 'MENU':
this key is used for navigating between the menu items and setting the values for menu items. This key doesn't have a
function when the user is not inside the 'MENU', meaning, pressing this key will not produce any impact when the user
hasn't invoked the 'MENU'. The ·flow chart given in Fig. A2'.9 illustrates the implementation of' UP' key handling.
The 'Down Key Handler' function implements the handling of the 'DOWN' key in different contexts. Inside the
'MENU', this key is used for navigating between the menu items and setting the values for menu items . This key doesn't
have a function when the user is not inside the 'MENU', meaning, pressing this key will not produce any impact when
the user hasn't invoked the 'MENU'. The flow1chart given in Fig. A2. l 0 illustrates the implementation of 'DOWN' key
handling. · '
 · Introduction to Embedded Systems

Main routine
Timer Ointerrupt handler
start

l, Load Timer Owith count for generating

50 millisecond delay
2, Decrement Timer multiplier Counter
1. Initialise port 1 and port 2 (Display port)
2. Disable all inte1I11pts
3, Initialise stack pointer
4. Select register bank 0
5. Stop timer 0
6. Initialise LCD
7. Configure timer 0 for 16 bit timer
8. Load timer Owith ccunt for generating 50
millisecond delay 1. Reset timer multiplier counter to 20
9. Set Timer multiplier counter to 20 2. Increment seconds register
I0. Set current hour to 12
11. Reset current minute and seconds
Register to Oand day' to 'SUN'
12. Set the time format to 12 Hour format
13. Set the current time as AM
14. Set Time changed Flag
15, Enable Timer Ointerrupt & Run Timer 0 YES

I.Reset seconds register to 0

2. Increment minute register

YES
I. Display the Current Time on LCD line 1
YES
NO
and the 'HA VE A NICE DAY!' prompt I. Reset minute register to 0
on second line, 2. Increment hour register
2. Reset Time changed Flag

YES

'Key Handler'
Check for key press and handle it accordingly

NO

NO
Yffi

NO Hour register=
Hour register-12 NO
Complement AM/PM bit

NO

YES YES
NO
Reset day register to 0 I. Reset hour register to 0
2. Increment day register NO

(!) Connects between the marked points

Indicate time changed
(Time changed Flag = l)
 Design Case Studies

'Key Handler' Start

Scan Row O(Clear Pl.0, Set P 1.1)

Wait for Key De-bounce

MENU Key Handler YF.S
Period

t+--------No-------...., NO

Wait for Key De-bounce

ESC Key Handler YF.S Period

NO

1+---------NO--,.-------' Scan Row I (ClearPl.l,SetPI.O)

Wait for Key De-bounce

UP Key Handler YES Period

. I NO

Wait for Key De-bounce

DOWN Key Handler YES Period

NO
NO

Return
 Introduction to Embedded Systems

MENU key handler

start

1. Set hour to the temporary hour

register value
2. Set AM/PM to the temp am_pm bit
YES 3. Reset submenu 2 counter to
zero (0)
4. Reset submenu 1 counter to
zero (0)

~
Display 'Adjust Hour' on first line
and blank the second line

Return

YES

Set Submenu l
counter = menu Set menu counter
counter
YES
to l

I. Set minute to the

I. Set day to the temp
I. Set subrnenu 2 counter temporary minute reg
Set the temporary day reg value
Display the menu to I value
hour register value 2. Reset submenu I
corresponding to the 2. Set the temp AM/PM 2. Reset subrnenu I
to 12, temporary counter to zero (0)
menu counter on first selector bit to AM (0) counter to zero (0)
minute reg to 30,
line. The menu details temp day reg to 3,
V Is menu counter iemp format bit'to 0
mapping is given below. and temp am_pm bit
I = 'Adjust Hour' to0(AM) Display 'SELECT Display 'Adjust Minute' Display 'Adjust Day' on
2 'Adjust Minute' AM/PM' on first line and on first line and blank first line and blank the
3 'Adjust 'Day' AM on the s~cond line the second line second line
4 = 'Adjust Format' Display 'Adjust Hour' NO
Display the temporary on first line blank the
register valu~s for the second line
selected menu item on
second line. Return Return Return

Return

Return

Yl;,S

I. Set format to the temp format bit value

NO
2. Reset submenu 1 counter to zero (0)

Display 'Adjust Format' on first line and

\ blank the Second line

Return

(Fig:. A2.8) ··flp~. cliart:for i~pl~men;ttrtg~l,VIE?ijJ' Key handler

-- '
 Design Case Studies

UP key handler
start

I. Complement temp AMIPM bit

2. Display'AM' on second line if
YES
temp AM/PM bit is 0. Otherwise
'PM' on second line
NO

Return

YES
NO

YES YES

Increment temporary Increment temporary Increment temporary

hour register minute register day register

Return

YES NO
NO YES

Reset menu counter to I

NO

____ ___
NO Reset temporary Reset temp day to 0
minute register to 0
NO ,._
Display the menu YES
corresponding to the Display 'Adjust Minute' Display 'Adjust Day' on
menu counter on first on first line & temp first line & the day
line. The menu details Set temporary hour minute on second line
register to I corresponding to temp
Vis menu counter · 'Day' register on second
mapping is given below. line. The day details V/s
I 'Ai:ljust Hour' temporary 'Day' register
2 ='Adjust Minute' mapping is given below.
3 ='Adjust 'Day' O='SUN'
4 ='Adjust Format' !='MON'
Blank the second line 2='TUE'
YES 3 ='\VED'
4='THU'
Set temporary hour 5 'FRI'
Return register to 0 6='SAT'
Complement
temporary Format bit
Display 'Adjust Hour'
Return
on first line terrip hour
on second line NO Display'Adjust Format' on first line & the
format corresponding to temporary 'Format'
bit on second line. The format details Vis
temporary 'Fonnat' bit mapping is given
Return below.
O= 12
I =24

Return

(Fig:,A2.9) Flow charffpr implem,enting 'UP' Key Mlld.-l~r

 Introduction to Embedded Systems

Down key handler

start

I. Complement temp AM/PM bit

:Z. Display 'AM' on second line if
temp AM/PM bit is 0. Olherwise
'PM' on second line.
NO

Rerurn

YES
NO

YES YES

Decrement temporary Decrement temporary Decrement temporary

hour register minute register day register

YES NO
NO YES

Reset menu counter to 4

NO Reset temporary Reset Temp Day to 6
NO
minuie register to 59
NO
Display the menu YES -----'----,
corresponding to the Display 'Adjust Minute' Display 'Adjust Day' on
menu counter on first on first line & temp first line & the day
line, The menu details Set temporary hour minute on second line.
register to 12 corresponding to temp
Vis menu counter 'Day' register on sei:ond
mapping is given below. line. The day details V/s
l = 'Adjust Hour' temporary'Day' register
2 ='Adjust Minute' mapping is given below,
3 ='Adjust 'Day' 0='SUN'
4 ='Adjust Format' !='MON'
Blank the second line 2='TUE'
YES 3='WED'
4='THU'
· Set temporary hour 5 ='FRI'
Return register to 23 6='SAT'
Complement
temporary format bit
Display 'Adjust Hour'
on first line and temp Return
hour on second line NO Display 'Adjust Format' on first line & the
format corresponding to temporary 'Format'
bit on second line. The format details V Is
temporary 'Format' bit mapping is given
Rerurn below.
0= 12
I =24

Return
 Design Case Studies

The 'ESC Key Handler' function implements the handling of the 'ESC' key in different contexts. Inside the 'MENU',
this key is used for traversing to the previous menu and finally to come out of the 'MENU'. This key doesn't have a func-
tion when the user is outside the 'MENU', meaning, pressing this key will not produce any effect when the user hasn't
invoked the 'MENU'. The flow chart given in Fig. A2.11 illustrates the implementation of' ESC' key handling.

ESC key handler

start

l. Reset submenu 2 Counter

to zero (0)
YES 2. Display 'Adjust Hour' on fast
line and the temporary h.our
register value on second line
NO

Return

YES

Reset submenu l counter to zero (0)

NO
Get main menu counter
ESC key pressed
Reset menu counter (Qo back to previous menu)
outside menu
to zero (0)

Return
Display the menu corresponding to
the menu counter on first line. The
menu details Vis menu counter
Indicate time ch.anged mapping is given below.
(Time changed flag =I) l = 'Adjust Hour'
2 = 'Adjust Minute'
3 = 'Adjust 'Day'
4 = 'Adjust Format'
Return Blank the Second line

Return

(Fig. A2. l l) Flow chart for implementing 'ESC' Key handler

Now comes the final part, implementation of the firmware requirements, which are modelled above, in Assembly
Language. The firmware implementation is given below.
H##tlJHhlt•Hif###llf.#flf##U#.#U#######H##########U'it##i##:jtlf.#U#*
Hfocik;;;,~\:\'h' :?·t ·,< . . · · •. · · · ·· · .•· ' · ., ·'. · · <
'tni:/ Cur:terit
··· •
)Ja'y
~fuli.1'e'r " ·
~rid Time, .
?:J21''•"200 8 ' .
J .
1
/f'lffftl ft'#lfitiflt*::tlfii:it'tilf***f#lfl##JH##At#tiF###Ufltii;i./t.##
,_ ,,,/''-'."·_·: __ ·.,:-:i}tt!::t<-:://•:·-''j(/~:-: ,;, ~<"> ;"·<;\_''.·,:_ ',.." _,' . '; ·';··< ..-- -<-,-__;''_(.,.

t 1f-9-c:e · ~eta11ff t
seti9,t'kf 2;hii;~t:ed to Po{f
. .· . , -
Pl. 4
 Introduction to Embedded Systems

;Read/Write Gonnected to Port Ptn Pl.5

;LCD Enable EN connected to Port Pin Pl.6
.• :; :LCD Data pt~ co~nected Port 2 tc/
; ###########'########U##U#O###################UH###############H
RS EQU Pl.4
RW EQU Pl .5
EN EQU PL6
LCD-"D~'.I'~ \< ' , •.•• "'.. EQU P2
; LCD .Coinmanci Detailj;
: 'FDNCJj~N~iE/J QATA .. ;.2 line i3 bit' interface
, .ENTRY:+!ODE·.· '' 06H
;;'CLEAR~tED · 61H .
;~'LCD::::QN' ,i . ; ' ·. ,:DATA .. OCH ; ,,.·
ttD '.HOME i\:,:, ,_ ::;~'~TA' '" , ,.. ",. . 02~ ' ,' ·'to h~µ}:ef:, pos~tion
; B'i·J·ng :"c:Ur~'or
·•LINE ... 1 DATA ' B.OH ;Addres;,' o.f .Fi:r:st line start
LINE::c2 · • · DATA }i,<,;:'oif· ;i>.ctar~ss of 'second' line start
LINE 2 9DI~rr. OC)$ (Add;;ss:o'f ·/h',Cen·:in 2~d "Line
LINE 2
5DIGIT 'rJAiA ...'ocBH ;Addr~ss. 6f 1it:"ti C~ll i~ 2nd' Line
':LINE 2 4DIGIT DATA.. . OCCH ;Add_rE:ss of 12t~ <:::~J-1 in 2nd Line·
·LINE 2 3DIGIT DATA:' ' · · OCDJ;i '\Address of 13th C.ell · in 2nd Line
LINE_ 2_2DIGIT DATA 'QCEH . ; Address of 14th Cell in 2nd Line
_LINE_}_1DIGIT. DATA. ; OCFH •. :1 . •fAdciress o.f IStti Cell
in:2nd Line
;###U##H######UUUUU#l##UU#####U.###H####U###U##f######### · .•
·· ;Keyboard interface details
; #U#U:##H##HHH#UH#U###OH:U.#H#H###H#####HH~#ihfft.######
ROW .0 EQU Pl. 0
ROW 1 EQU Pl ;1
COLUMN O EQU Pl.2
COLUMN 1 ·EQU PL3
; # ## H It#### H ## ###H# #### H ### # ##H ######Hf########### #H # ## ### #### #
;Memory location/Register. Assi~nm'ent':Details
;Registers or memory locations fo'f ·hour, minute, seconds, day,
;time format flag, AM/PM flag and_ Time-changed flag
;Main Seconds Register: R7
;Main Minute Register: R6
;Main Hour Register: RS
;Main Day Register: R4
;Timer multiplier Register: R3
;####################################################################
HOUR REG EQU RS
MINUTE REG EQU R6
SECONDS REG EQU R7
DAY REG EQU R4
TEMP SECONDS EQU 30H
TEMP MINUTE EQU 31H
TEMP HOUR EQU 32H
TEMP DAY EQU 33H
I
SEIT FORMAT OOH
SBIT AM PM OlH
SEIT TEMP FORMAT 02H
SBIT TEMP AM ·PM 03H
SBIT TIME CHANGED 04H
-
;The memory locations for Holding the information on
;which all menus are traversed
MAIN MENU COUNTER EQU 35H
SUEMENUl COUNTER EQU 36H
 Design Case Studies

SUBM.ENU2_COUNTER EQU 37H

;l#ll#l####ll###l####l##ll#l##l####l##f###l#####lll#ll#ll#t##tlltll##
oRG Ooobff ;Reset vector
JMP 0050H ; Jump to code mem location 0100H to
;start of execution
ORG 0003H External Interrupt O ISR location
RETI ; Simply return. Do nothing
ORG OOOB~ ; Timer O Interrupt ; ISR loc~·tion
;T]::le ISR will nbt fit in 8 bytes ... Mq.ke,:H a.
;s1.1br<)U~ine · and .Ci;tll :the r;utinE::::· •. '
~A~L TrMERO INTERRUPT: · ··· · · ··
RETI Return
. 'ORG 001¥!{ Extif~~f Int~'fI:upt';1 ·I:,R 1~cation
'RETI ' Sj,It,1ply r:etµrn .• P9<no.t:hi11g; .. •·
OR~ d;QIBH mi~eEl In,(~ritJP~ I~R ,location
·RETI [S/~p}y·re\~;r_-rt.it~~:•nqt9ing ·:;,\··
ORG o623H Sed:~l In't~~rtipt,;;rsR, l°'c:.atioQ '
. . RETI ;,Si;;pl,y ~eturh.\Do nqthing •.• . ..
;IUll}lifll#til###ll##ll####l#l#ll##l~~ftlfl#lit#i#l###l##f##lltl##I
; $t9;rt of ma.in Program
ORG 0050H MOV Pl, #OFFH Ini tiafrse · Port ;l
MOV P2, #OFFH . Initial,isi Po:i:t 1
CLR . EA .oi~ral5le .Ail J.n ferr~riit~ .•. i/
. MOV SP, #50H S.Elt sta9k at memory .locatiort' 50!{ .
'CLR RSO Se1ec.t Register Bapk O
'•"• C .• '••
·,, ¥

;CLR RSl
CLR TRO
CALL INITIALISE LCD
Configure Timer O as Timer in mode 1 · (i6 bit Timer)
MOV TMOD, 100000001b
MOV TLO, #0B~H
MOV THO, #3CH
The multiplier for the time delay generated by Timer
MOV R3, #20
CLR A
;Current Day, Time, Bour Format and AM/PM Initialisation
MOV HOUR REG,#12 Set Current Hour to 12
MOV MINUTE_REG, A Set Current Minutes to 0
MOV SECONDS_REG, A Set Current Seconds to 0
MOV DAY_REG, A Set Current Day to SUNDAY
CLR FORMAT; Set the time format to 12 Hour format
CLR F.M PM Set the current time as AM
MOVIE, 110000010b; Enable only Timer O interrupt
SETB TRO ; Start Timer 0
SETB TIME CHANGED ; Set Time changed Flag to-
; refresh LCD
CHECK_UPDATE:JNB TIME_CHANGED,SKIP_R~FRESH
CALL DISPLAY TIME
CLR TIME CHANGED
. I
\
SKIP REFRESH:CALL KEY HANDLER
- '
;Check whether inside menu. If yes loop till exit
MOV A,MAIN_MENU_COUNTER
CJNE A,#OOH,SKIP REFRES1-J
- J
JMP CHECK UPDATE
;ltlll##ll##ll#l#l##l#.lll##lllll##ll####l#l##llllll#lltll##l##l##t##I
I
; SUBROUTUINE FOR DI,SB,LAYING TIME
 Introduction to Embedded Systems

Displays Time inn DAY HH:MM:SS "on First line and

"HAVE A NICE DAY!" on second line
Input: DAY , HOUR_REG, MINUTE_REG, SECONDS_REG, DPTR
Output: None
;########################¥.###########################################
DISPLAY TIME: MOV. A,.#LINE_l
CALI; SEND COMMAND
MOV DPTR,#TEXT_2BLANK
CALL DISPLAY STRING
-
;Pass the DAY_BEG Value through Accumulator
;Retrieve the String value for DAY corresponding-
;to the DAY inde~ passed
MOV A,DAY_REG
CALL GET DAY STRING
;Adjust DAY_R.EG If it holds an invalid value (>6)
;The GET DAY STRING Loads Accumulator with 0, if
;DAY_REG > G
MOV DAY_REG,.A
CALL DISPLAY STRING
MOV A, #' '
CALL DISPLAY CHAR
MOV A,HOUR_REG
CALL DISPLAY NUMBER
MOV A,# I : I
CALL DISPL~Y_CHAR
MOV A,MINUTE_REG
CALL DISPLAY NUMBER
MOV A,#' : '
CALL DISPLAY CH~R-
MOV A,SECONDS_REG
CALL DISPLAY NUMBER
MOV DPTR,#TEXT_2BLANK
CALL DISPLAY STRING
MOV A, #LINE _2
CALL SEND COMMAND
MOV DPTR,#TEXT_NICEDAY
CALL DISPLAY STRING
RET
;####################################################################
; Key Handler
;• Handles the key press.
Implements the Row-wise scanning of Keyboard ·keydebouncing.
; Input: None
; Output: None
;####################################################################
KEY HANDLER: SETB COLUMN 0 ;Configure Column O Pin as inpuc pin
SETB COLUMN 1 ;Configure Column 1 Pin as input pin
CLR ROW 0 ;Scan Row 0
SETB ROW 1
JB COLUMN 0, CHECK ROCl
;Menu key press detected
;Wait for keydebounce time, 20 milliseconds
MOV RO, #20
CALL MILLISECOND DELAY
JB COLUMN 0, INVALID_PRESS
;Menu Key press is valid
 Design Case Studies

;Call menu handler Routine

CALL MENU KEY HANDLER
RET
CHECK ROCl:JB COLUMN 1, SCAN ROWl
;ESC key press detected
;Wait for keydebounce time, 20 milliseconds
MOV RO, #20
CALL MILLISECOND DELAY
JB COLUMN_l, INVALID_PRESS
~ESC Key press is valid
·. ; Call iE~c' Key handler Routine
,. •ctLL, tsc KEY- HANDbER.
~:r
SCAN •ROWl.: cr;i\.:11ow ',l : Scan Row
}ik'i'B Jt◊~-0
JB COLUMN~O, CHECK RlCl
;UP key press det~cted
;Wait
,,-·
forkeydebounce
''
time, ., ' '

MOV RO, ¾20

CALL MILLISECOND DELAY
JB COLUMN 0, INVALID PRESS
·:;UP K~y ·P-;~1·s
is .::alid ·
;Call UP Key handler Routfne
CALL UP KEY HAND1ER
RET
CHECK_RlCl:JB COLUMN 1, INVALID_PRESS
;DOWN key press detected
;Wait for keydebounce timE; 1 ~20 mfll,isecdrids ·
MOV RO, #20 ..
CALL MILLISECOND DELAY
JB COLUMN 1; INVALID_ PRESS
;DOWN Key press is valid
;Call DOWN handler Routine
CALL DOWN KEY HANDLER
INVALID PRESS: RET
;#########lt##########################lt################lt####Jt####.Jt####
;MENU KEY HANDLER
;Handles the MENU Key press in Main menu, Submenu 1 and Submenu 2
;Inputs: SUBMENU2_COUNTER, SUBMENUl_COUNTER, MAIN MENU COUNTER
;Output: None
;########'############################################################
MENU_KEY_HANDLER:MOV A,SUBMENU2 COUNTER
;Check whether inside Submenu 2
CJNE A,#OOH, INSIDE_SUBMENU2
JMP CHECK SUBMENUl
;lnside Submenu 2
;Se~ Hour to the temporary hour register value
INSIDE SUBMENU2:MOV HOUR REG, TEMP ROUR
;Set AM/PM to the temp am_pm bit
MOV C,TEMP_AM PM
MOV AM_PM, C
;Reset :Oubmenu 2 Counter to zero
CLR A
MOV SUBMENU2_COUNTER, A
;Reset Submenu 1 Counter to zero
MOV SUBMENUl COUNTER, A
 ...
, .:··-:
'f
,k,"'_.;·i,
Introduction to Embedded Systems

;Display 'Adjust Hour' on First Line and

;blank the Second line
CALL DISPLAY HOUR BL
RET
CHECK SUBMENUl: MOV A,SUBMENUl_COUNrER
;Check whether inside Submenu 1
CJNE A,#OOH, INSIDE_SUBMENUl
;Not inside Submeru 1
. ; Check whetp.~r inside Main Menu
~p CHECK MMNMENU
; Inside sub.menu 1 ·_
.INSIDE !3UBMENU1 :· CJNE :.i,'tO).H; ADJOST,MINUTE
E~tir'. from~· s{ib~~;:-u 4.
2
; Indici;te ·1~side -s'ubttle~u
MOV 'i§'.tiBMENU2 'c:OUNTER, Ac ,.
MOV .A>hINE 1 •' ,
, CA:LL SEND COMMAND .
. MOV DPT'R/tTEkT~)1MPM ·
CALL-DISPL'Ai STRING
;Default'AM/PM to AM
; F.or AM the· bit should be reset. -!Eh~ _,TEMP ''AA Pij bit
;is complemented inside DISPLAY AMi>~ · · ·-:- ·.,,-;:::•::, ·
'sETB \l'EMP AM PM . - ·•
. · · ; Display _tlie AM/PM on second Line ·
_CALL DJ;SPLAY_AMPM
RET
. ;Reset· Submenu '/J. Counter to zero
•. AIJJUST MINUTE: MOV SUBMENUl iCOUNT.ER, #OOH.
CJNE A,#02H, ADJUST_DAY
;Set Minute. to the t:empo,rary hourregist~r value
MOV _'MINUTE_;:REG, TEMP _MINlJTE ·.,
;Display 'Adjust Minute' ,pn First Line
;Blank the second line of LCD
CALL DISPLAY MINUTE BL
RET
ADJUST DAY: CJNE A,#038, ADJUST_FORJViAT
;Set Day to the temporary Day register value
MOV DAY REG, TEMP~DAY
;Display 'Adjust Day' on First Line
;Blank the second line of LCD
CALL DISPLAY DAY BL
_RET
1
ADJUST FORMAT: CJNE A,#04H, SUBMENUl INVALID
;Set FORMAT to the temp format bit
MOV C,TEMP_FORMAT
MOV FORMAT, C
; Display 'Adjust Format' on First L.~_,ne
;Blank the second line of LCD
CALL DISPLAY FORMAT BL
SUBMENUl INVALID:RET
CHECK MAINMENU: MOV A,MAIN_MENU_COUNTER
CJNE A(#OOH, INSIDE_MAINMENU
;Outside Mainrnenu
MOV MAIN_MENU_COUNTER, #1
;Set Temp Hour Reg to 12
MOV TEMP_HOUR, #12
 Design Case Studies

;Set Temp Minute Reg to 30

MOV TEMP_MINUTE, #30
; Set Temp Day Reg to WED .( 3)
MOV TEMP_DAY~ #3
;_ Set Te!'l\p AM~PM to AM
;The common Subroutin~. DI~PLAY AMPM-complements-
;this bit. Hence take the inve,:se logic
"SETB TEMP_;.AM_)M ,,
; Set Temp FORMAT to ·,12, .
CLR TEMP FORMAT

. =. ,
INSIDE MAI~NU:~Q;,l
:iiiiii~Ji~f~[tlil:;·
$UBMENU;l, q:JUNTER,.A... , ,

~5i}f;:f!!i~ii~t;:~s~td~d*li
Mov ·A; -'llEMr" .Houi. · · ·
;f~" ·
CALL -DISPI;'A'Y'
'
HR:MT
- -
RET
INSIDE MINUTE: CJNE A;itD2H, INSrDE DAY ,,·. _.
::,,: ";'I;'he Sllbmenh· 1'.;~rect~d ,Is Minute,·,
, ., > , ), ;_'3/s,; l "'<'':"*A
.,.··}.~}'. ,>-_..;!,''','.
); ·;.;_'-' : ,_v •. ,.,., - . •,

· -;Di~Pi?tY t}ie"telllp__ minute on ,,se'c9nd,

Mov' "A; TEMP MINUTE· ·
.:/cALL DISPLAY HR MT",, "
RET · :,- · , '-
.I,NSI,DE :DAY: '··c&Nf A, #b3H, INSIDE __)'ORMAT
; The Submenu, 1 selected Is DAY'
; Display the String for· temp' Day on. s.econd line
Mov':A,, TEMP_DAY · ··-·--- ,.. --
. CALL GET DAY STRING .
;Perform day correction if'.day passed i:S invali-d
MOV TEMP_DAY,A
MOV A,#LINE 2 SDIGIT
CALL SEND COMMAND
CALL DISPLAY STRING
RET
INSIDE FORMAT: CJNE A,#04H, INVALID.:_MENU
;The Submenu 1 selected is Format
;Display the temp format on second line
CALL DISPLAY FORMAT
INVALID MENU: RET
;####################################################################
;Subroutine for Displaying the hour/minute on the last 2 cells of
;the second line of LCD.
;The hour/minute value to be displayed on LCD is passed through-
;Accumulator Register A
;Input Variable: Accumulator
;Output Variable: None
;####################################################################
DISPLAY HR MT: PUSH ACC
MOV A,#LINE_2_2DIGIT
CALL SEND COMMAND
POP ACC
~hL~PLAY_NUMBER
EET...
 Introduction to Embedded Systems

;################ll############li#ll#ll###l###############l###l###I##
; Subroutine for retrieving the 'DAY string corresponding to the day
;index passed. The Day inqex is passed through Accumulator
;Input Variable: Through Accumulator Register
;butpui: Variable: The start.address of the corresponding string is-
;loaded in DPTR register.
;###l#ll####l##i##l##~#l#l#######f##l##fi######ll#llltll#lll#l#lll#I#
GET DAY.STRING: CJNE .A, #OH, IS_:MONDAY
MOV. DP'.J.'R, #TEXT 'qUN
ru;f' . . - . .
IS.MONDAY:.
·- .,,,
\
GJNE:A
.
;<#if!
·_ :,'. /
;rs'••iuEtfr)A;
·-;~/ ... ·" ,-~- •··. ~-: :~
:. ·-~ ' ,,,

MOV'.:IJP:TR,.#TEXT :MON
t
REi l' "'.\ ' \ • >·:1 : ,-::
IS TUESD~Y: . "' >.,·., :nH
._cJNE~:A _;: .-,.·-'· ·-.-rs
:· _. ,,_,WEDNESDAY
' . -- '
.MOV Df.'.I'R, #cfE.XT~.TUE, . •. .
RET
IS WEDNESDAY: .. ' CJNE A'; #3J!, IS. THURSDAY '
"MOV D~:TR/#TEXT ~WED .... ,. ,.
RET , ,.. . - ..
IS THURSDAY: CJNE A, 14H, TS FRIDAY
MOV DPTR, ITEXT THU ' .
RET ... . . " -· ..
IS FRIDAY: CJNE .J\;• #5H,' ,fS'SA'I'URDAY
MOV D#TR,#:TEXT___:FRI
RET
IS SATURDAY: c'.:JNE Ar '.#6H, INVALID DAY
MOV DPTR, ITEXT'.SAT
RET,
0 .... -
INVALID DAY: MOVA, #OOH
MO\( DPTR,#TEXT~SUN
RET
;.f#l#######H##lll#l##lll#ltl##H###l##UIIHl####IU.1##1####11######
;Subroutine for Displaying t~e Time Format on th~ last 9 celli of
;the second line of LCD. The bit corresponding to the Format string-
;to be displayed on LCD is passed through TEMP FORMAT bit
;Input Variable: TEMP_FOR.MAT bit
;Output Variable: None
;#####l######l####l###l####J#l###l#l#####il#l##############i#####II##
DISPLAY FORMAT: JB TEMP_FORMAT, NXT_HOUR FORMAT
MOV DPTR, tTEXT _ 1·2HR
JMP DISP- HOUR- FORMAT
NXT HOUR FORMAT: MOV DPTR,#TEXT_24HR
DISP HOUR FORMAT: MOV A,#LINE_2_9DIGIT
CALL SEND COMMAND
CALL DISPLAY STRING
RET
;##l#####l##J##l#ll##ll#l#l######l#l#l########l#######l####lt########
;Subroutine for Displaying AM/PM on the last 4 cells of the second-
;line of LCD. The bit corresponding to the AM/PM string to be-
;displayed on LCD is passed through TEMP_AM_PM bit. This bit is-
;complemented first. This helps in calling this subroutine for-
;handling boLh UP/DOWN key in Submenu 2 (for AM_PM Adjust)
;Input 'l.ariable: TEMP_AM_PM bit
; Output Vari_able: None
;##l#ll#ll#l#######l#############l########l#l###l#ll##l#l######f##I##
 Design Case Studies

DISPLAY AMPM: CPL TEMP AM PM

JB TEMP_AM_PM, AFTERNOON TIME
;The TEMP_AM_PM is in reset state
;The time is morning. Display AM on second line
MOV DPTR,#TEXT_AM
JMP DISPLAY AM PM
;The TEMP AM_PM is in set state
;The time is Afternoon. Display PM on second line
AFTERNOON TIME: MOV DPTR,UEXT_PM
Dr:wtAY: .Af'.i PM= Mov A,JLINE 2 4DIGIT
CALL SEND COMMAND
CALL DISPLAY STRING

;###i###########U##~~:#'U##O####U########iH#H#lH######{~####:if##'
; ,.E$¢ 1<:EY ,HANDLER
0

;Hafidles 'the ESCKey pr"ess in Main menu, Subm~nu 1 c!cfld •$ubmenu''2: ; •.

/?Iriput,s: SUBMENU2;,COUN'I'ER, S,UBMENUl COU!'lT.ER, ,J1AINiMENu:._coUNTER, (
}outp;l~, None ·· - ·· · :,ti- ,,
;,¥lit:ftfit##liflt####ifit##f0tll-H####U####it#Oiit##lt####H#.lt#fllH####'#f#n·.
ESC KEY HANDLER: MOV A, SUBMENU2 _ COUNTEf
·.,;Check whether inside ·,_submenu·:-2 .
CJNE A, #OOH, ESC~IN_3UBMEN1J_2 ...
;Not inside Submenu_ 2
;Check whether inside Submenu,1.
JMP ESC _ CHECK_:S'UBMENUl
;Inside Submenu 2 ·
; Ge back to the previous menu·
ESC'TN SUBMENU2: ;Reset Submenu 2 Counter· tozero
CLR A
MOV SUBMENU2_COUNTER, A
;Display 'Adjust Hour' on First Line
MOV A,#LINE_l
CALL SEND COMMAND
MOV DPTR,#TEXT_HOUR
CALL DISPLAY STRING
;Blank the second line
MOV A, HINE 2
CALL SEND COMMAND
MOV DPTR,fTEXT_LCD BLANK
CALL DISPLAY STRING
;Display current temporary hour on the Second line
MOV A,TEMP_HOOR
CALL DISPLAY HR MT
RET
ESC CHECK__ SUBMENU1: MOV A, SUBMENUl COUNTER
;Check whether inside Submenu 1
CJNE A,#OOH, ESC_IN_SUBMENUl
;Not inside Submenu 1
;Check whether inside Main Menu
JMP ESC CHECK MAINMENU
;Inside Submenu 1
;Reset Submenu 1 Counter to zero
ESC IN SUBMENUl: MOV SUBMENUl COUNTER, #OOH
;ESC pressed inside submenu 1
/, ;Call che common subroutine for handling ESC key
;inside submenu 1 and UP/DOWN key in main menu
 Introduction to Embedded Systems

CAL~ MAIN SMl CMNHLR

RET
CHECK MAINMENU: MOV A,MAIN MENU COUNTER
- CJNE A,.#OOH; Esc_=-rnsIDE_MAINMENU
;ESC Press Outside Mainmenu
;Do Nothing
RET
INSIDE_MAINMENU:;ESC_from Main Menu
;Reset all menu re.lated counters
CLR A
J\1()V MAIJ:l'_MENU- COUN'J;'ER, A
MOV SUBMENU;J. :COUNTER, A
"'Mov
,q, suBMENb2;coiJNTER,
,,,,,, ·, ·,~·-~ ,, A
St,,t Ti.me ¢hanged nag.
,;This is mandatory for Refr~shing ):,CD -Dis'plaY
SETB TIME CHANGED .
.-R.El!'
##1#l#####lf##l~#'##l#####llt##!.######.######J###H#t'U'.U·H#Ji~#Uf#U.
Common Handle~ for ,ESC key in Submenu ·1 and;:rjpJDOW!'J Kiy .. iri~Maih>M'e~u
Han(iles ESC.Key in.Submenu 1 and UP/DOWN Key M;in
Menu
;Bef~re Calling .thi.s PJll.tine, Accumulator Regfster >slrould be lOaded-
' .; with the value Sub~'enu 1 counter or maih. menu counter
;Accuinulat:9:i;- Register
: 'None
,.;;; ##### ### #H ##### ### # # # # #.### #### # ## # ## # u ##It######### I###"###### ####h
;MAIN_:~Ml~CMNHL'B,:C3Np A, #OlH, SMl_ADJQST MINUTE
;ESC from•Submenu 1
CALL DISPLAY HOUR BL
- -
RE'l'
. SMl_ADJUST_MINUTE:CJNE A,#02H, SM~DJUST_DAY
CAtt DISPLAY MINUTE BL
- -
RET
SMl_ADJUST_DAY: CJNE A,#03H, SMl_ADJUST_FORMAT
CALL DISPLAY DAY BL
RET
SMl ADJUST FORMAT: CJNE A,#04H, SMl INVALID
CALL DISPLAY FORMAT BL
SMl INVALID: RET
;#######1###############11########1###1####11#########1#1############
;UP KEY HANDLER
;Handles the UP Key press in Main menu, Submenu 1 a~d Submenu 2
;Inputs: SUBMENU2 COUNTER, SUBMENUl __COUNTER, MAIN_MENU COUNTER
;"Output: None
;################11#######1#1#1###1#1###1########1#1#11#######1######
KEY HANDLER: MOV A,SUBMENU2_COUNTER
;Check whether inside Submenu 2
CJNE A,#OOH, IN_SUBMENU2
;Not inside Submenu 2
;Check whether inside Submenu 1
JMP UP - CHECK- SUBMENUl
;Inside Submenu 2
;Complement AM_PM
UP IN SrJBMENu2: ;Display the AM/PM on second Line
CALL DISPLAY AMPM
RET
UP CHECK SUBMENUl:MOV A,SOBMENUl_COUNTER
 Design Case Studies

;Check whether inside Submenu 1

CJNE A,#00H, UP_INSIDE~SUBMENUl
;Not inside Submenu 1
;Check whether inside Main Menu
JMP UP CHECK MAINMENiJ
UP INSIDE SUBMENU1:
CJNE A, #0lH, UP ~ADJUST_MINUTE
;Inside Adjust Hour Menu
;Increment Temp ·Hour:by 1
.· .MOV A., T.EMP HOUR: . -
INC A ,,;h''"'
. ~· ·>:·r: . .. . . . ·. . . ,. > , .- < .•.
Check the' Eime fo:dnat•:... 'for. 12. hour fc/rri\at; reseJ-

i~~~f I!l1~~~[!f~!!!~(tL ·. . .. .
UP HOUR SMl RTRN}MOV TEMPiHOUR, A
- ,_')v? ,:----'' '•• , ' (•-' , "'. ,.:•.,,

; Display the '.temp hour on seci;)np Jine ,

CALL DISPLAY i-lR'MT
RET
UE' HR FORMAT_24 :C.JNE A,#24, UP_HOUR_SMl RTRN
; For .. 24 hour format, reset the 'Terrip_J-!our to 0-
; if Temp_hour > 23
CLR A
MOV TEMP_HOUR, A
; Display the tei,np hour· on second line
CALL DISPLAY HR MT
RET
iJP ADJUST MINUTE: CJNE A,#02H, UP_ADJUST_DAY
;Inside Adjust Minute Menu
;Increment Temp_Minute by 1
MOVA, TEMP_MINUTE
INC A
CJNE A,#60,UP_MNT_SMl RTRN
;Reset the Temp_Minute to 0-
;if Temp_Minute > 59
CLR A
UP MNT SMl RTRN:MOV TEMP_MINUTE, A
;Display the temp minute on second line
CALL DISPLAY HR MT
RET
UP ADJUST DAY: CJNE A,#03H, UP_ADJUST FORMAT
;Inside Adjust Day Menu
;Increment Temp_Day by 1
MOVA, TEMP DAY
INC A
CJNE A,#7,UP_DAY SMl RTRN
CLR A
UP DAY SMl RTRN:CALL GET DAY ·STRING
MOV TEMP DAY,A
~Display the DAY string on second line
;DPTR Register holds the start address of the string
MOV A,#LINE_2_5DIGIT
CALL SEND COMMAND
CA1L DISPLAY STRING
RET
 Introduction to Embedded Systems

UP ADJUST_FORMAT:CJNE A,#04H, UP_SMl_INVALID

;Toggle Temporary Format bit
CPL TEMP FORMAT
;Display the current temp format on second line
CALL DI;3PLAY FORMAT
UP SMl INVALID: RET
;Check whether inside mainmenu
UP_CHECK~~AINMENU:MOV A,MAIN_MENU_COUNTER
. CJNE A,# O.OH, \JP_ IN_MAINMENU
;UP Key pressed Gutside menu
;~po 'n0thlng
---~T
·,
UP K,ey pre;;E/eQ iq~J;d~;m.c1_tri.,fi!e1';1s> _
.;Scroll down .. in m~iri rri~pu _ · _. · , . _ " ·, '

.,/I,~cr~ment the main in$'riu counter,\Jor ,this .

UP. IN t-W,.INMENU: I.NC_'!>,,
_:cJNE A, #5, UP WITHIN LIMIT
i;t ~·'.~~MdV ,.A/·#1 >- ', "•¾

.. up wrirHIN- LINITlM:bi:tMArn· MENU cotrNTERfA

- - ·- ' ; Display the. main menu item_ corresponding to. the
; riew menu -counter
- CALL t:fAIN_SMl _ CMNHLR
i ·- < ·,_ •-• • ' ,.: ;_;, :)RET . . .- . . .. .. . . .
J'#U·###O#lf##l####::lf##################U#H##U###H#UUU#####lt##H#
;DOWN-Klt.Y HANQ1.iER
;.Handles_:the·. DOWN .Key press in Main menu, Submen:u 1 a11ci Submenu 2
- ; Inp~ts; - SUBMENU2 .cfoUNTER, SUBMENUl COUNTER, ::MAIN MENU rnµ.&TER
.; Output: None _ _ -_,_ - _ _ - _- _ - ·
; -IHI##### U#U#Af*J## U# U###### ##H#####H#H########U# ##############
'_DOWN_KEY_ HANDLER :MOV A, SUBMENU2 _ COUNTER
;C}:leck whether inside Submenu 2
CJNE A,#00H, DN_IN_SUBMENU2
;Not inside Submenu 2
;Check whether inside Submenu 1
JMP DN CHECK SUBMENUl
;Inside Submenu 2
iCOmplement AM_PM
DN IN SUBMENU2: iDisplay the AM/PM on second Line
CALL DISPLAY AMPM
RET
DN_CHECK_SUBMENUl:MOV A,SUBMENUl_COUNTER
;Check whether inside Submenu 1
CJNE A,#00H, DN_INSIDE SUBMENUl
;Not inside Submenu l
;Check whether inside Main Menu
JMP DN- CHECK- MAINMENU
;Inside Submenu 1
DN INSIDE SUBMENUl:
CJNE A,#0lH, DN_ADJUST MINUTE
;Inside Adjust Hour Menu
;Decrement Temp_Hour by 1
MOVA, TEMP_HOUR
DEC A
;Check the time format. For 12 hour format, reset-
;Temp_Hour to 12 if it goes below 1
JB FORMAT, DN HR FORMAT 24
 Design Case Studies

CJNE A,#0,DN_HOUR SMl RTRN

MOVA, #12
ON HOUR SMl_RTRN:MOV TEMP_HOUR, A
;Display the temp hour on second line
CALL DISPLAY HR MT
RET
ON HR FORMAT_24:CJNE A,#OFFH,DN_HOUR_SMl_RTRN
; For 24 hour format reset the Temp_Hour:, to ·23-
; if Temp_hour < 0
MOVA, #23
MOV TEMP_HOUR, A
;Display.the tE;mP hour on second lJne
CALL DISPLAY HR MT
RET
DN_ADJUST_MINUTE: CJNE A,lf02H, DN_ADJUST DAY
;Inside Adjust Minute Menu
;Decrement Temp_Minute by 1
MOVA, TEMP:._MINUTE
DEC A
CJNE A,tOFFH,DN MNT SMl RTRN
;Reset the Temp_Minute to 59-
;if Temp_Minute < 0
MOV A,#59
ON MNT SMl RTRN:MOV TEMP_MINUTE, A
;Display the temp minute on second line
CALL DISPLAY HR MT
RET
DN_ADJUST_DAY: CJNE A,#03H, DN_ADJUST_FORMAT_
;Inside Adjust Day Menu
;Decrement Temp_Day by 1
MOVA, TEMP_DAY
DEC A
CJNE A,#OFFH,DN DAY SMl RTRN
MOVA, lf6
DN DAY SMl RTRN:CALL GET DAY STRING
MOV TEMP_DAY,A
;Display the DAY st-ring on second line
;DPTR Register holds the sLart address of the string
MOV A,#LINE 2 SDIGIT
CALL SEND COMMAND
CALL DISPLAY STRING
RET •
DN ADJUST FORMAT:CJNE A,#04H, DN~SMl INVALID
;Toggle Temporary Format bit
CPL TEMP FORMAT
;Display the current temp format on second line
CALL DISPLAY FORMAT
DN SM1 INVALID: RET
;Check whether inside mainmenu
DN_CHECK_MAINMENU:MOV A,MAIN_MENU_COUN'JER
CJNE A,#OOH, DN IN MAINMENU
'·; DOWN Key pressed outside menu
; Do nothing
RET
;DOWN Key pressed inside main menu
 Introduction to Embedded Systems

;Scroll Up in main menu

;Decrement the main menu counter for this
DN IN MAINMENU: DEC A
CJNE A,#0H, DN_WITHIN_LIMIT
MOV A, #4
DN_WITHIN LIMIT:MOV MAIN_MENU_COUNTER,A
;Display the main .menu item corresponding to the
; ne~1 menu counter
CALL.MAIN_SMl-'CMNHLR.
RET
;#Htt##O#!#l##:it########tt#########4ft##t##t#ttt.t##J#.t###UH##H##Jfo.#
, ';~Jsp}iy/':A<:ijl!.s<tl;ur' on Fir~t Line'; arid:;bf~tik;'..£ir~ 'i~o0nci lin,,j• . ,
; Inp\.it:·;;Non'e ,. . ,.
';out~.ut•: ii'one
;'#####UH###HUl#####UU#UH###HH####i#it!tHif#HUH#l###t#ltH#
DJ-SPLAY--·HO.UR
' .'"'-
BL:MOV A,#LINE
" ' -
1
CALL,SEND_COMMAND
MOY DPTR,#TEX'I!.'_HOUR
CALL DISPLAY STRING
MOV A,#LINE_2
CALL SEND COMMAND
MOV DPTR,#TEXT_LCD:.:_BLANK
DISPLAY STRING
RET · . .
; 1uuu11#1ntu#u1#1u1uuu#######~#n~t~,~Hi:u.#1.vJJ}U#H*•ioi
; Display 'Adjust Minute' on First Lin~ and blank the Second
,'.\ _, ,: ' ,, '':'>,,'

;Input: None
;Output: None
;#########t##################################tt##t#tf####t#t#########,
DISPLAY- MINUTE- BL:MOV A, #LINE_:1
CALL SEND COMMAND
MOV DPTR,#TEXT_MINUTE
CALL DISPLAY STRING
MOV A,#LINE_2
CALL SEND COMMAND
MOV DPTR,#TEXT LCD BLANK
CALL DISPLAY STRING
RET
;####################################################################
;Display 'Adjust Day' on First Line and blank the Second line
;Input: None
;Output: None
;###########t#t#########################l######II####################
DISPLAY DAY_BL:MOV A,ILINE 1
CALL SEND COMMAND
MOV DPTR,ITEXT_DAY
CALL DISPLAY STRING
MOV A,#LINE_2
CALL SEND- COMMAND
MOV DPTR,#TEXT_LCD_BLANK
CALL DISPLAY STRING
RET
;###1#1#####11#####1######1############11#####1######1###1########1##
;Display 'Adjust Fo~mat' on First Line and blank the Second line
;Input: None
;Output: None
 Design Case Studies

;#######1###############1#######11###################################
DISPLAY_FORMAT_BL:MOV A,#LINE_,_1
CALL SEND COMMAND
MOV DPT~, JTEXT _ FORMAT
..CALL DISPLAY_STRING
.MOV A, #LINE_2
CALL SEND COMMAND
_MOV DPTR, #T.EXT_ LCD_BLANK
CALL DISPLAY,.. STRING
~-::-
RET. . ..
r######-#it##H###l#####H#################Ul,##i######################
; LCD ~nitialisiition Routine.
rlsJtiroµtpi~ foti initiafrsing LCD._'
. ; ·wrrtten for_.OR:IOtE ODM16.11 .Module, .· ..
R~'fer to th~ i;co Datasheet for timing paramet§rs' and commands
]z'inE) ,tune tllis_ subroutine i:,S per the_ LCD Modu'J,'e.'.
+~t:>-~f! None · · ·
Output:. None _
; ##H######H#################lt############t#####lt############HH###
INITIALISE:LCD: MOV A,#FUNCTION_SET
I CALL WRITE COMMAND

MOV A, #FUNCTION_ SET

CALL WRITE COMMAND

~ov A,#FUNCTION_SET
CALL WRITE COMMAND

MOV A,#FUNCTION_SET
CALL SEND COMMAND

MOV A, #ENTRY__MODE
CALL SEND COMMAND

MOV A,#CLEAR_LCD
CALL SEND COMMAND

MOV A,itLCD_ON
CALL SEND COMMAND
RET
;#####lt#lt####lt#######ii##########l#####l#i#####l#l###lt#l########l##I#
; Subroutine for w_ri ting to the command register of LCD with 'BUSY'
;checking. Command to be written is passed through Accumulator
;Input: Accumulator
;Output: None
;####llt##lt##l#l#l##ll#l####lt#########l###l###############l##l###l##I#
SEND COMMAND: SETB P2. 7 ;Configure Pin P2.7 as input Pin
CLR RS ;RS=0, Select Command Register of LCD
SETB RW ;RD=l, Read Operation
READ BUSY: SETB EN ;Toggle LCD Enable to generate a High to
CLR EN ;Low transition. This latches the data
JB P2.7,READ BUSY ;Loop till Busy Flag is Reset
MOV r·P2, A ;Load Display port with the command
CLR RS ;RS=0, Select Command Register of LCD
CLR RW ;RD=0, Write Operation
SETB EN • ;Toggle LCD Enable to generate a High to
 Introduction to Embedded Systems

CLR EN ;Low transition. This latches the data

RET ;Return
;########l#######l####f#ll#####l##l################f#################
· ;Subroutine for writing to the command of LCD without-
;' BUSY' checking. Before writing to the command register, waits for-
;100 millisecond. Command to be written is passed through Accumulator
· ; Input: Accumulator
. ;Output: .None·.
· ;######1###-###########H########H#########l#######H################
WRITE __:CO~ND: MOV P2, 'A
CLR RS ;RS=O, Select Command Register of LCD
CLR RW ;RD=O, Write 'Operation
SETB EN . ; Toggle LCD Enable to ""''""'"'·;, a High to
EN ;Low transition. This latches the data
MOV RO, #10.0
CALL-MILLISECOND DELAY.
RET
;################################f##########I########################
;String Display
l
Subroutihe
;This Routine 'Displays a string on the LCD Screen
;DPTR cont~ins the start address of the String
;The character# indicates the string termination
. ;Input: DPTR Register
;Output: None
;#############H.###############H####ltHltH#H##lt#ltlt####Hlt##.######1#
DISPLAY STRING: CLR A
MOVC A,@A+DPTR
CJNE A,#'#' ,CONTINUE
RET
CONTINUE: CALL DISPLAY CHAR
INC DPTR
SJMP DISPLAY STRING
;#lt##f######lt#####f#lt#lt##lt##ltlt###lt##########################lt###lt####
;Subroutine for generating milliseconds delay
;ms Parameter passed through RO
: RO
; Output: _None
;#############l####i#########################ltlt##########lt########lt##
MILLISECOND DELAY:
MOV Rl,#250
DELAY LOOPl: NOP
NOP
DJNZ Rl,DELAY_LOOPl
DJNZ RO,MILLISECOND DELAY
RET
;lt#######lt#ltltlt###########lt####lt#####lt#lt######lt####tlt####ltlt##lt#######lt
;Roucine for Displaying a Character on LCD
;The ASCII Value of the character to be displayed is passed through A
;Input: Accumulator Register A
;Output: None·
;t############lt##ltlt#####lt######lt###lt########lt####lt#lt############ltlt##t
DISPLAY CHAR: SETB P2.7 ;Configure Pin P2.7 as input Pin
CLR RS ;RS=O, Select Command Register of LCD
SETB RW ; RD=l, Read Operation
CHECK BUSY: SETB EN ;Toggle LCD Enable to generate a High to
CLR EN ;Low transition. This latches the data
 Design Case Studies

JB P2.7,CHECK_BUSY
MOV P2, A ;Load LC[) __ Data bus .with Data
SETB RS ; RS=l, :select Data Register of L~o·_,
CLR. RW ;Rb=:-.0,Aai/rit~ Operation
SETB EN ;;J;og:gle~LCD Enable to gen02rate .a High
CLR EN ; Low 't:ransition. This 1a'tches .the ·

;ff t~UfttJl{•!t0¥~~!flif}if!J'ifJtfl!ifft),~•ttfUtffUftUttttO_f.tttt
·; S1>broutiqe for..Displcl..ying a' de.cimaJ. nul'Qber .in the range-. . .
;,o ;:tc'.i~ 99ft:o ;o;te§~bndirtg ASCII. D1s~lay:f:tJ1e ASCII valu?
:•; ntimb'~t on~";seco~~L Hn~ of ,'.LGD'::·bt-J po's'i:tiion•,ieart':ing frcin{:a.<1

:'.t~t~~!~t1:!f~~~~jJ}J~1i[!ttfJ~~~J: .
·Out!pu '• one' : "'" -~:. •,,,, ,;_;;-_;:i'..:(c . .•.

;.o •t~ v*!, 1.i~* tt, • uu, * ri1

:f>IPLAY_::~HJ~ER~, Mb\T 'RO ,.f2 .· ·
i _ f tJ • 1•.• u 1
; •.• ' .
uH-t:t•·tftJH
tlifHtJt
·:.,:tC:;_: /_;;: ) ', : i''• :r -~ n1\;: t-Hit
·-:
MOV ,i3, AHO
DIV AB
XCH A,B
• XCH A,B
ADD A,··j30H
~ CALL DISPLAY CHAR
DJNZ B,0;LOOPl
' ' ,, ., -.. •, .... :: ,R:ET ·. ' ·. ' ' ' ' , ' '." ' ••
;HitH###H#.####.UO#U#####UUU##U##HU#UHfrlf##U###U#OJit##U ·.
; Tiinel:"o 'i~te"ri:Gpt Routine C ✓·, . ' .•• ' ,,, .,,. ' w:
• • ·• ; • <,

; Occu'rs ~t "iy::s-o. mlllisecunds. 20. consecutive· interrupts gener·a~e-·

; 1 seccinctji~ •··; ,
; Input: :R3 :;JTimer Multiplier)
;Output: .SEfONps REG, HOUR REG, MINUTE REG, DAY REG, AM PM
/HH##l/###'lfltitJ4tf####H####Ui##t##H#################it#tlF###########
' • "•'•" 'v,•,'•'•• w·c ' v ' :_ • •

TIME0 INTERRUPT:
;Reload timer 0 with a count for 50 milliseconds
MOV TL0, #0B4H
MOV THO, #3CH
PUSH ACC ; Save Accumulator
PUSH PSW ; Save PSW Register
;Check whether 1 second is elapsed. One timer
;interrupt corresponds to 50ms. 20 consecutive
;timer interrupts generate 1 second. This is
;implemented by loading a timer multiplier register-
;with 20. This is decremented on interrupt.
;A value of 0 for this register indicates 1 second
;delay happened.
DJNZ R3, TIME NOT_ELAPSED
MOV R3, #20
;1 Second elapsed. Increment seconds Register
INC SECONDS REG
CJNE SECONDS REG, #60,DISPLAY_UPDATE
;60 Seconds elapsed. Reset Seconds RegisLer and
;Increment Minute Register by 1
MOV SECONDS_REG, #OOH
INC MINUTE REG
CJNE MINUTE_REG, #60,DISPLAY_UPDATE
;60 Minutes elapsed. Reset Minute Register and
 Introduction to Embedded Systems

;Increment Hour Register

MOV MINUTE_REG, #OOH
INC HOUR REG
;Check the time format. For 12 hour format change-
;the day when hour goes beyond 12 and the time-
;tr.ansition from PM to AM
JB FORMAT, HOUR FORMAT_24
G:JNE HOUR'-REG,# 13, DISPLAY_UPDATE
. C~R C
. MOV A, BPUR .REG
;1f' the existing tiwe· ftirmat0 was'. 2,4hr arid '.the. uset:
._.;;ch~i~9. it .th1(0ygh
. . ;greater than 12;.>:,,,
t~~r·'i:qh{t' 1'.1e~~ .if
This may" resµlt, in'. errone~us · ·
;~bf:·~~it;:i~
' , •.~ ,.•_'✓ ~~, , "' :- ';~,3/ . y, ~•i, _,:'",: ' ;:__ .• -, ' . , ,·"::, . ' ' •---~ ' '/C ". •. : ~ ' , v ·,

· ; result. So ·use the foliowtng set .of instruct.ion.s,

;Oth~rwise it slJould ha;;,,{'b~e~ repJaced~hy'MOV
;HOUR'REG, #1
SUBB ,'IZ;'t12· .
MOV HQ'tJR_REG, A
CPL AM PM
'
JB AM_PM, DISPLAY_UPDATE l
'CHECK DAY: ,. INC DAY REG I
I.•

;~~set da:y _to· SUNDAY (0) if it overflows -beyond

;SATURDAY (6)
CJNE DAY-'REG,#7, DISPLAY UPDATE
MOV DAY_REG, #0
DISPLAY UPDATE: SE;T:S TI~_C~NGEQ
TIME NOT ELAPSED: BOP PSW ; Retrieve PSW
POP ACC . ;Retr~eve Accµmu:j.~tor
RET
HOUR FORMAT 24: CJNE HOUR_REG,#24,DISPLAY_UPDATE
; For 24 hour format re.set the hour to Oand chang12
;the day when hour goe's beyond 23
MOV HOUR~REG, #0
JMP CHECK DAY
;####################################################################
· ;Define the String Constants to be displayed on LCD for different-
;Menus. The String is stored in code memory after the above-
;instruction. The start address for each string constant is-
;indicated by the text label. ;The character# is used as string-
;terminator
; Some strings are aligned for 16 characters by packing with blank
;#################################################################### I
TEXT NICEDAY:
DB 'HAVE A NICE DAY!#'
TEXT HOUR:
DB ADJUST HOUR #'
TEXT MINUTE:
DB \
ADJUST MINUTE #'
TEXT DAY:
DB ADJUST DAY #'
TEXT FORMAT:
DB ADJUST FORMAT #'
TEXT AMPM:
DB SELECT AM/PM #'
TEXT 2BLANK:
DB #'
 Design Case Studies

TEXT; LCD BLANK: ,

'. $ .. ~ ._. '.
: ;~ii.t§.Vtf.=., : -.. · - t :.\ .,.;,
' f !?.U~]J-,' ~
J

The timer interrupt generates 'seconds' timing with a tolerance of 1 to 6 microseconds/Second. This code may not be
optimised for code size or perfonnance. Fine tuning of the code, instruction usage, redundant and dead code elimination,
I

.
I
I•
etc. are left to the readers as an assignment.
l

Smartcard is a credit card sized plastic card containing a memory or a 'CPU and memory'. Smartcard contains memory
in the order of a few bytes to a few kilo bytes. Smartcard follows a specific command sequence for data read/write opera-
tions. The data read write operation is controlled by a Sman:card Reader/Writer IC. Based on the interface between the
Smartcard and the Reader unit, smartcards are classified as 'Contact type' and 'Contactless'. The Contact type smartcard
requires physical contact between the reader and the smartcard. The contact type smartcard follows the ISO-7816 stan-
dard and its physical contact looks exactly the same as that of the contacts of a GSM cell phone's SIM card. Whereas the
contactless smartcard doesn't require a physical contact between the reader and the smartcard for data communication.
The data communication for a con tactless smartcard happens over air interface and it uses radio frequency waves for data
transmission. 13.56 MRz is the commonly used radio frequency for smartcard operation.
· We are going to design a battery operated contactless smartcard reader (Handheld Reader). A rechargeable Li-lo bat-
tery (Say 7V with capacity 1000mAh) is used as the power source for the handheld. The battery parameter (capacity and
voltage) monitoring and charging is controlled using a battery monitor and charge control IC (Like DS2770 from Maxim
Dallas Semiconductor). The host processor can be an 8 or 16bit·microcontroller (Like 8051 or PIC family of controller).
The device power ON is controlled through a push button switch. A single chip contactless smartcard read/write IC is
used for data read write operation with the smartcard. The smartcard reader IC is interfaced to the host processor and
the data communication will be under the control of the host processor. The smartcard read/write IC contains CPU (Or
control logic implementation), read/write memory, analog circuits for data modulation and demodulation, transceiver
unit for RF data transmission and reception, and antenna driver circuitry. For the handheld reader to communicate with a
j desktop machine, a communication channel using either USB or RS-232C is implemented in the reader. The I/O unit of
the system includes a matrix keyboard for user inputs and a graphical/alpha-numeric LCD for visual indications. LEDs
are used for various status indications like 'Charging', 'Battery Low', 'Busy/Error', etc.
 Introduction to Embedded Systems

The Oscillator and Reset circuitry generates the necessary clock and reset signals for the proper operation of the
host processor and smartcard read/write IC. The watchdog timer unit provides the necessary reset to the system in case
of system misbehaviour. Sometimes the watchdog timer hardware comes as part of the host processor; if not a separate
watchdog timer IC is used. The watchdog interrupt is connected to one of the interrupt lines of the processor: Most of the
microcontrollers contain built in data memory and program memory. If the on-chip program and data memory are not
sufficient for the application, external data memory and program memory chips can be used in the design. The block dia-
gram depicted in Fig. A2.12 illustrates the various components required for building the handheld, contactless smartcard
reader.
The firmware requirements for building the handheld smartcard reader can be divided into the following tasks.
1. Startup task
2. Battery monitoring and Charge controlling task
3. Card read/write operation task
4. Communication Task
5. Keyboard scanning task
6. LCD update task
7. Watchdog timer expire event

Antenna

The communication task and keyboard scanning task can be implemented either as a polling task or an interrupt driven
task. The watchdog timer expiration event is captured as an interrupt.
The startup task implements the necessary startup operations like setting up the interrupts, configuring the ports of
the host processor, initialising the LCD, initialising the battery monitor and charge control IC, initialising the smart card
·reader IC, etc.
 Design Case Studies
■. .
The battery monitoring and charge controlling task reads the various registers m 0 1tage capa 'ty · t t ) fth ·
· h k th f h d · •. ' v• , 01 reg1s ers, e c. o e
battery momtor IC, c ec s e presence o a c arger an m1tlates a charge command, terminates the h • · h · th.· .
. . 1 h th b 1 . b1 c argmgw en e
battery is full, produces warning ~1~a w en e attery v~ tage 1~ e ~w a thr~shold value and switch off the unit ifthe
battery voltage falls below the cnt1cal threshold value. This task is assigned highest priority to avoid data corruption m
case of a power down.
The card read/write operation task is responsible for implementing the communication sequence for data read/write
operation with the card. The smartcard read/write operation follows a specific sequence of operation. The sequence varies
with the standards (Like ISO/IEC 14443 A/B, ISO/IEC 15693, etc.) supported by the read write IC. A typical read write
operation follows the sequence:
1. Reader initiates a 'Request' command for checking the presence of cards in the vicinity of the reader. If a card is
present in the field it responds to the reader with Answer To Request (ATR).
2. Upon receiving the ATR, the reader sends a command to capture the serial number of all cards present in the field.
Most of the reader ICs implement special algorithms to decode and capture the serial number of all cards present
in the field.
3. Reader selects the serial number of a card from the list of serial numbers received and sends a command to select
· the specified card. The card whose serial number matches with the one sent by the reader responds to the reader and
all other cards in the field enters sleep state. Now the communication channel is established exclusively between
the reader and a card.
4. The Reader authenticates the card with an encrypted key. If the key matches with the key stored in the card, the
authentication succeeds. Different security mechanisms are useq by different family of cards and readers for
implementing authentication.
5. The reader sends a read/write command to the card along with the details of the memory area which the reader
wants to read/write and the data to write in case of a write operation. The memory of the card is segmented into
different sectors and each sector may be further divided into blocks. Each block holds a fixed number of data bytes.
Each memory segment contains a key for authentication. The. memory organisation of the card is manufacturer
specific.
The keyboard scanning task scans the keyboard and identifies a key _press and performs the operation corresponding
to the key press. This can be implemented as a task or an Interrupt Service Routine if the keyboard hardware supports
interrupt generation on a key press.
The LCD update task updates the LCD with new data. This task can be invoked by other tasks like keyboard scanning
task, battery monitoring task, card read/write task and communication task for displaying the various infonnation.
The communication task handles reader communication with the host PC. The communication interface can be either
USB or RS-232. This task can also be implemented as Interrupt Service Routine. Most of the processors support Serial
Interrupt for handling Serial data transmission using UART and RS-232. If USB is used as the interface, the interrupt
line of the USB ch1p can be connected to the Interrupt line of the processor and communication can be controlled in the
ISR.
The watchdog timer expiration ISR handles the actions corresponding to a watchdog timer event.
The firmware for controlling the handheld reader can be implemented in either a 'Super loop' model where the tasks
are executed in sequence in a super loop with interrupts running in the background or using an RTOS scheduler like uC/
OS-II or RTX-51. or VxWorks for scheduling the tasks.

An Automated Meter Reading (AMR) system automates the utility metering (like electricity, water and gas consump-
tion). AMR technique replaces the existing manual meter reading operation. AMR systems transfer the meter reading
data automatically to a central station or operator for billing and usage monitoring purposes. The meter reading data is
transferred over a wireless communication channel or a wired communication medium. Radio Frequency (RF) transceiv-
ers, GPRS based communication over GSM network are examples of wireless AMR dat_a transfer, whereas Power Line
Communication (PLC) in electricitymetering is an example for wired AMR data transfer. PLC uses the power carrying
lines for data communication with a substation. The AMR system contains an AMR data transmission unit, which is
interfaced with the utility meter and a remote AMR data receiver unit which collects the data for billing and usage moni-
 Introduction to Embedded Systems

toring purpose. The AMR data transmission interface can be built as an integral part of the utility meter or can be built as
an add-on module for existing utility readers. Nowadays, Application Specific Standard Product (ASSP) ICs integrating
both utility metering capability and AMR interface is available for building a utility meter with integrated AMR interface.
The AMR enabled utility meter can also be built using a low-cost microcontroller with an AMR interface. Our discussion
is focused only on AMR interfaces for enfrgy metering for single phase power supply.
The implementation of a microcontroller-based AMR enabled energy metering device is shown in Fig. A2. l 3. It con-
tains an energy metering .unit and a wireless/wired automated meter reading interface. The energy metering unit records
the electricity consumption. A single chip energy meter IC forms the heart of the energy metering unit. It contains a high
performance microcontroller (typically a 16bit RISC microcontroller), integrated ADCs and LCD controller, etc. The
instantaneous power consumption in an electric circuit is given as P = VI; where V is the instantaneous voltage and I is
the instantaneous current. The .electronic energy meter records the current consumption by integrating the instantaneous
power. The instantaneous current is measured using a current sensor circuit. The current sensor circuit essentially con-
tains a current sensing resistor and an instrumentation amplifier for signal conditioning. The signal conditioned current
value is fed to the energy metering IC. The ADC present in the energy metering IC digitises the instantaneous current
value. The voltage sensor circuit senses the instantaneous voltage and it is fed to the energy metering IC for digitisation.
The microcontroller present in the energy metering IC computes the instantaneous power, the average power consump-
tion and stores it in the EEPROM memory. It also displays the parameters like instantaneous current, voltage, electricity
consumed in KWh units on an LCD through a built-in LCD controller interface. The MSP430 chip from Texas Instru-
ments is a typical example of a single chip energy metering IC.

Wired AMR interfa~e

(power line communication)

(Fig.,A2.13) Block Diagram of an AMR enabled Integrated E~ectronic.Energy M~ter

The Automated Meter Reading (AMR) interface to the energy metering unit can be provided through an RF interface
or through Power Line Communication (PLC) module. The RF based wireless AMR interface is best suited for short
range automated reading applications like handheld device based recording of energy consumption. The meter reading
official carries a handheld for recording the energy meter reading through a Wireless AMR interface. The specific energy
meter whose reading is to be recorded can be selected by sending the unique meter identification number (Meter ID) of

l
 Design Case Studies

the meter and then initiating an automated meter reading operation. The RF interface consists of an RF Transceiver (RF
transmitter cum receiver), and impedance matching circuit and an antenna for RF data transfer. The impedance matching
circuit consists of capacitor, resistors and inductors and it tunes the circuit for the required frequency. The RF tra11sceiver
unit is responsible for RF Data modulation and de-modulation. The antenna is a metallic coil for transmitting and receiv-
ing RF modulated data. The interface between the energy metering 'unit and the RF module is implemented through serial
interfaces like SPI, I2C, etc. The firmware running in the microcontroller of the single chip energy meter IC controls the
communication with the RF module.
The Power Line Carrier Communication (PLCC) based AMR interface makes use of a power line modem for inter-
facing the power lines with the energy metering unit for data communication. The PLC modem provides bi-directional
half-duplex data communication over the mains. The PLC modem can be interfaced to the microcontroller of the energy
metering unit through serial interfaces like UART, SPI, etc. The firmware running in the microcontroller controls the
communication with the PLC modem. Texas Instruments' F28x controller platform provides a cost-effective means to
implement PLC technology. -
GPRS based data communication over GSM network is another option for implementing AMR interface for long
range communication. A GPRS modem is required for establishing the communication with the GSM network. The
GPRS modem can be interfaced to the microcontroller of the energy mete.ring unit for data communication. ZigBee, Wi-
Fi, etc. are other wireless interface options for AMR interface.
The firmware requirements for building the AMR enabled energy meter can be divided into the following tasks:
1. Startup task ·
2. Energy consumtion recording task
3. Automatic meter data transfer task
4. LCD update task
The 'Startl)p task' deals with the initialisation of various port pins, interrupt configuration, stack pointer setting, etc.
for the microcontroller, initialisation of the RF interface for the communication parameter, and initialisation of the LCD.
The energy consumption task records the energy consumption. The energy metering SoC may contain dedicated hard-
ware units for calculating the energy consumption based on the instantaneous voltage and current and the meter reading
will be available in some dedicated registers of the SoC. The energy consumprion recording task can read this register
periodically and update the EEPROM storage memory (Which may be part the SoC.or an external chip interfaced to the
SoC). Tue automatic meter data transfer task can be implemented as a periodic task or a command driven operation in
which the meter reading is sent upon receiving a command from the host system (the system which requests energy con-
sumption for billing and usage purpose like the central electricity office or handheld terminal carried by the meter reading
official). For the command driven communication model, a set of command interfaces are defined for communication be-
tween the AMR enabled meter and the host system. Each AMR enabled meter holds a unique Meter ID and the firmware
can be implemented in such a way that the AMR module responds only when the Meter ID sent by the host along with
the command matches the Meter ID stored in the EEPROM of the Meter. Tue LCD update task updates the LCD when
a change in display parameter (like instantaneous current and voltage, energy consumption, etc.) occurs. These tasks can
be implemented in a super loop with interrupts or under an RTOS like uC/OS-II. The firmware requirements in the super
loop based implementation is modelled here with the flow chart as shown in Fig. A2. l 4.

4. DIGITAL CAMERA.
Digital camera is a device for capturing and storing images in the form digital data (series of ls and Os) in place of the conven-
tional paper/film based image storage. It is atypical example of an embedded computing system for data collection/storage
application. It contains a lens and image sensors for capturing the image,LCD for displayingthe captured image, user interface
buttons to control the operation of the device and Communication interface to connect it with a PC to transfer captured images.
Figure A2. l 5 given below illustrates the various subsystems of a digital camera,
In today's digital world people are accustomed to digital devices. Indeed they use digital camera for capturing their
favourite moments in life. But how the camera converts their favourite moments into a digital picture is still a surprising
thing to most of them. Let us have a closer look at the internals of a digital camera to explore its functioning. FigureA2.16
illustrates the various components of a digital camera.

l
 Introduction to Embedded Systems

Serial interrupt routine

Main Routine Start

Initialise the Microcontroller

Initialise the RF Interface
Initialise the LCD

Receive Interrupt Handling

1. Read the received data
2. Check the received meter ID with EEPROM
Read the instantaneous voltage, stored value. Respond to command if Meter
Current and average energy consumption ID matches. Else do nothing
Record the reading in the EEPROM 3. Rest of the processing
Display the parameters on LCD
Transmit interrupt handling
Handle transmit interrupt
Wait for sometime i
1'

Return

-----Lense en
lat
D1
User interface buttons ~ - - - - -
elt
dii
Te
al1
un

th1
zo
(L

ba

ca
et1

c___ _ _ TFT LCD and touch screen m

pr
(rtg..82.15) --~~!; -~ of_~p~~e~f:~~~a pe
(Pqptq_ .· rfe~ of tf-BJI9)
us
I
Design Case Studies

Like a normal film camera, it uses a lens to focus the scene which is going to be captured as an image. The only differ-
ence is in 'how the scene is captured'. In a normal film camera, the image is captured in a photo film and the photo film is
later develop,,ed-to recreate the image, whereas in a digital camera, the image is captured electronically. Charge Coupled
Device (CCD) or CMOS image sensors are used for capturing the image. When exposed to light these sensors produce
electrons which in tum generates analog voltage signals. These analog signals are post-processed (filtered, amplified and
digitised) by an Analog Front End (AFE) system. Analog Front End ICs are available from various manufactures like
Texas Instruments. The digitised data is supplied to a Digital Media processor, which implements various compression
algorithms like JPEG, TIFF, etc. for compressing the raw image data. The digital media processor may contain a DMA
unit to transfer the compressed, digitised image directly to the storage memory. .
The various system functions like shutter control and zooming control is performed by the 'System Control' unit of
the camera which is implemimted using a 16/32 microprocessor/microcontroller. Stepper motors are used for shutter and
zoom control. The system control unit is also responsible for handling the I/0 (Buttons) and graphical user interface
(LCD control).
The digital camera is powered by a re-chargeable battery and the monitoring and charging control is carried out by a
battery charge control and monitoring IC, which is under the control ofthe 'System Control Unit'.
Provisions for interfacing various storage memory devices like SD/CF/MMC cards are implemented in the digital
f camera. The camera device can be connected to a host PC through the communication interface (Like USB, IEEE 1394,
1 etc.) supported by the device, for image transfer.,
Nowadays, a single-chip called System on Chip (SoC), incorporating both image processing'unit and 16/32 processor
in a single ICare available and they simplify the de~ign. The resolution of a digital ca~era is expressed in terms of mega
pixels. You may be familiar with the terms 3.2 mega pixels, 5.1 mega pixels, 7.2 mega pixels, etc: It represents the_pixds
per inch of the.image sensing device (CCD/CMOS). As the number of pixels increase, the image quality also increases.
The various syst~m control tasks and image capturing and processing tasks f~r the digital camera are implemented
using an embedded operating system.
 1. Intel® 8051 Data sheet
·- 2. Fundamentals of C Programming, Kernighan & Ritchie (K&R)
3. Atmel In System Programming (ISP) Guide
4. Computers in Spaceflight: The NASA Experience
(http://www.hq.nasa.gov/office/pao/History/computers/Ch2-5.html) on history of Apollo Guidance Computer (AGC)
5. Wikipedia (http://en.wikipedia.org/wikiD on the history of embedded systems
6. Microsoft Developer Network (http://msdn2.microsoft.comL)
7. FireWire 2.2.2 and 2.3.3: Information and Download
http://docs.info.apple.com/article.html?artnum=86020 .
8. IEEE p1394 Working Group (1996-08-30), IEEE Std 1394-1995 High Performance Serial Bus, IEEE. ISBN 1-5593-7583-3
9: WiFi Wireless LAN Data Rates and Range
hllp://www.networkdictionary.com/Wireless/WiFi-Wireless-LAN-Data-Rates.php ,.
10. USB Complete: Everything You Need to Develop Custom USB Peripherals, Jan Axelson, published by Lakevtewresearch Ile,
2005, ISBN. 1931448027, 9781931448024
_:---
11. Quick reference for RS485, RS422, RS232 and RS423 http://www.rs485.com/rs485spec.html
12. Latest ZIGBEE SPECIFICATION including the PRO Feature Set from Zigbee Alliance
http://www,zigbee.org/en/index.asp
13. Home Networking with Zigbee, Mikhail Galeev
http://www.embedded.com/columns/technicalinsights/18902431? requestid=94796
14. ZigBee Wireless Networking Overview, Texas Instruments
http://focus.ti.com/lit/ml/slyb l 34a/slyb 134a.pdf
15. Piezo Electric Sound Components Application Manual, muRata
http://www.murata.com/catalog/p 15e6.pdf
16. CMOS: Circuit Design, Layout, and Simulation, revised second edition, Baker, R Jacob (2008), Wiley-IEEE, ISBN 978-0-470-
22941-5. http://CMOSedu.com/
17. The VLSI Handbook, second edition (electrical engineering handbook), Chen, Wai-Kai (ed) (2006), Boca Raton: CRC, ISBN
0-8493-4199-X
18. 82C55A Datasheet from Intersil Corporation. http://www.intersil.com/data/fn/fn2969.pdf
19. MicroCIOS-II: The Real-Time Kernel, Jean J. Labresk CMP Book, ISBN: 1-57820-103-9
20. AVR Instruction set summary . '.
http://www.atmel.ru/Disks/AVR%20Technf~al%20Library/appnotes/pdf/AVR Instruction set.pdf
21. Datasheet of PIC J6F877http://wwl.micrbchlp.com/downloads/en/DeviceDoc/30292c.pdf'
22. ARMArchitecture Reference Manual, David Seal, Addison-Wesley; 2nd edition, 2000. ,
23. AMBA Specification (Rev 2.0) © Copyright ARM Limited 1999 ·. / "
24. 74Fl 48 8 to 3 encoder http://www.standardics,nxp.com/products/fast/datas~eet/74fl 48.pdf
25. Embedded Power Line Carrier Modem h.tm~//www.archnetco.com/english/product/ATL90.htm
 Bibliography

26. MCT2M, MCT2EM, MCT2JOM, MCT271MPhototransistorOptocouplers

http://www.fairchildsemi.com/ds/MC/MCT2-M.pdf
27. Trends in the High-speed Embedded Market
http://www.embeddedintel.com/market watch.php?market=643
28. Reconfigurable Processors: Changing the Systems Design Paradigm
http://www.embedded.com/192200275? requestid=25912
29. Reconfigurable So Cs http://electronicdesign.com/Articles/ArticleID/4861/4861.html
30. Inside the JAVA Virtual Machine, Bill Venners, McGraw-Hill, 1999, IS1:JN 0-07-135093-4
31. Java ME at a Glance http://java.sun.com/javanie/index.jsp
32. UML forum-UML tools list http://www.uml-forum.corn/tools.htm
33. IBM Software Design Tools
http://www-Ol.ibm.com/software/rational/offerings/architecture/softwaredesi g11.htrnl
34. The Unified Modeling Language Reference Manual, second edition, Grady Booch, James Rumbaugh & Ivar Jacobson, Addison-
Wesley, ISBN 978-0-321-24562-5
35. Tbe Unified Modeling Language User Guide, second edition, Grady Booch, James Rumbaugh & Ivar Jacobson, Addison-Wes-
ley, ISBN 978-0-321-26797-9
36. Hardware/Software Co-Design-Comes ofAge, David Maliniak
http://electronicdesign.com/Articles/Index.c:fin? AD= 1&ArticleID= 19301
37. Hardware/software Co-design: Principles and Practice, J0rgen Staunstrup & Wayne Hendrix Wolf, published by Springer,
1997, ISBN 0792380134, 9780792380139
38. 8-bit Flash Microcontroller AT89C51RD2/AT89C51ED2
http://www.atmel.com/dyn/resources/prod documents/doc423 5.pdf
39. DS80C320/DS80C323 High Speed Low-power Microcontrollers
http://www.maxim-ic.com/quick view2.cfm/qv_pk/2955
40. 8-Lead JEDEC SOIC Packag~ Material Declaration Data Sheet
http://www.atmel.com/green/documents/pmdds/SOIC JEDEC 8 Sn.pdf
41. SOIC Package details/or AT17LV65 from Atmel
http://www.atmel.com/dyn/resources/prod documents/doc232 l .pdf
42. TSSOP Package details for AT24CJ 024B from Atmel
http://www.atmel.com/dyn/resources/prod documents/doc5194.pdf
43. AD570-Cpmplete 8-Bit A-to-D Converter
http://www.analog.com/static/imported-files/Data Sheets/AD570.pdf
44. DM9370 7-Segment Decoder/Driver/Latch with Open-Collector Outputs
http://www.datasheetcatalog.org/datasheet/fairchild/DM9370.pdf
45. Use reentrant functions for safer signal handling
http://www.ibm.com/developerworks/linux/library/l-reent.htm1
46. Cx5 J Users Guide Listing (LST) File
http://www.keil.com/support/man/docs/C5 l/c5 l cm lstfile.htm
47. BL51 Users Guide Listing (MAP) File
http:/iwww.keil.com/support/man/docs/bl51/bl5 l In mapfile.htm
48. Cx51 Users Guide Object (OBJ) File
http://m.keil.com/support/man/docs/C5 l/c5 l cm objfile.htm
49. Cx51 Users Guide Preprocessor (I) File
http://www.keil.com/support/man/docs/C5 l/c5 l cm ifile.htm
50. Boundai)'-Scan Tutorial Ji-om Corelis Inc
http://www.corelis.com/products/Boundary-Scan Tutorial.htm
51. Bounda,y-Scan Description Language (E/SDL) 1i1torial, Cordis Inc
http://www.corelis.com/products/BSDL Tutorial.htm
52. Operating System Concepts seventh edition, Avi Silberschatz, Peter Baer Galvin & Greg Gagne, John Wiley & Sons, Inc.,
ISBN 0-471-69466-5
53. VxWorks® Programmers Guide 5.4, Wind River Systems
54. What is Programmable Logic? www.xilinx.cotn/company/about/programmable.html
55. Adidas Designs A Winner With "Smart" Running Shoes, Mark David www.electronicdesign.com/Articles/Index.cfm? AD= l&
ArticleID=l0113
)
#error 351 Interrupt Enable Register 121
.NETCF 650 Interrupt Latency 124
I-wire 49 Interrupt Priorities I 22
7-Segment LED Display 36 Interrupt Service Routine 123
8051 92, 164 IP Register 122
Addressing Mode 98, 165 RETI instruction 123
Direct 97, 165 IRAM 102
Immediate addressing 167 LCALLinstruction 124
Indexed addressing 167 Logical Instructions 185
Indirect 165 ANL 187
Register Addressing 166 CLRA 188
Architecture 94 CPLA 188
Arithmetic Instruction 177 ORL 188
Addition 178 Rotate Instruction 188
Decimal Adjust 184 SWAPAinstruction 190
Decrement 184 XRL 188
Division 180 Machine Cycle 105
Increment 183 MOVC Instruction 177
Multiplication 180 MOVX Instruction 175
Subtraction 178 Oscillator Unit 104
Bit Addressing 99 Paged Data Memory Access 98
Clock Speed 105 POP Instruction 123
Crystal Resonator I 04 Port 105
DAAinstruction 184 Alternate Pin Function 108
Data Memory 96 Port O 105
Execution Speed I 05 PORT 1 107, 108
High Speed Core 153 PORT3 108
Instruction Set 171 Read Latch 109
Arithmetic Instructions 177 Read Pin 109
Boolean instruction 190 Sink Current 111
Data Transfer Instructions 171 Source Current 110
Logical Instruction 185 Power Consumption 153
Program Control Transfer 193 Power on Reset 151
Interrupt System 121 Power Saving 151
External Interrupts 126 IDLE Mode 151
 Index

PCON Register 152 Advanced High Performance Bus 668

Power Down Mode I 52 Advanced Peripheral Bus 668
Program Control Transfer 193 Advanced System Bus 668
CALL Instruction 194 Aging 422
CJNE Instruction 195 AHB 668
CJNE instruction 195 AMBA 668
DJNZ Instruction 195 Analog to Digital Converter 127
Jump Instruct.ions 193 Android 652
Register Instructions 167 AOT Compil~r 650
Registers 102 APB 668
Accumulator 102 Application Specific Instruction Set Processor 19
B Registers I02 Application Specific Integrated Circuit 19, 26,647
Data Pointer 103 Application Specific Standard Product . 26
DPTR 103 Aritb.Q:letic Operation 321
Program Counter 103 Al<M- '664
Program Status Word I 02 Array 325, 344
PSW 102 ASB 668
Scratchpa_dRegisters 104 ASIC 19, 26,647
Stack Pointer I 03 ASIP 19
Register Specific Instructions 167 Assembler 309
Reset Circuitry 150 Assembly Language 583, 306
RET Instruction 124 Assembly Note 285
Serial Port 139 ASSP 26
baudrate 141 AT89C51 112
Mode0 140 AT89C51RD2/ED2 155
Mode 1 140 AT89S8252 112
Mode2 143 Atomic 364
Mode 3 143 auto 320, 321, 366
Multiprocessor Communication 143 Automotive 85
Receive Interrupt 141 AYR 657
REN 140
SBUF Register 139 Baudrate 140
SCON Register 139 BCD 184
Transmit Interrupt 14 l Big-endian 24
SFR 101 Bill of Material 262
Single Stepping 126 Binary Coded Decimal 184
Special Function Register 96 Packed 184
Stack 172 Unpacked 184
Stack Pointer 172 Binary Semaphore 467
Timer/Counter Units 132 BIOS 33
Auto Reload Mode 136 Bit field 346
GA.TE Control 134 Bit Manipulation 356
Mode 0 134 Bitwise AND 356
Model 135 Bitwise NOT 357
Mode 2 136 Bitwise OR 356
Mode 3 137 Bitwise XOR 356
TMODRegister 132 Bluetooth 56
T States 105 BOM 262
8052 Microcontroller l 55 Boot loader 553
8255A 42 BootROM 553
µVision3 558 Boundary Scan 608
Boundary Scan Description Language 610
Actuators 16, 35 Bounded Buffer Problem 451
ADC 127 Branching Instructions 322
 Index

break 320, 324 CPLD 26

Brown-out Protection Circuit 61 CPU Utilisation 404
BSDL 610 Critical Section 470
Buffer 231 CRO 607
Busy Waiting 457 Cross Compiler 319

calloc 369 Data Flow Graph 207

CAN 87, 94 Data Memory 21, 93
case 320 Datapath Architecture 205
Cathode Ray Oscilloscope 607 Data type 320
CDFG 207 ADC0801 127
char 320 De-multiplexer 236
Character 330 Deadlock 445, 449
Chiplevel Multi Processor 647 Debugging 570, 599
CIL 650 Decoder 233 •
Circular Wait 446 Decompiler 597
CISC 22,206 default 320
CLR 650 delay 355
CMP 647 Deployment 634
CMPXCHG 459 Detailed Design 631
Co-design 204 Device driver 476
Co-operating Process 426 Device Queue 405
Co-operative Multitasking 403 DFG 207
Code Memory 93 Digital Signal Processors (DSP) 6, 15, 22
Combinational Circuit 236 Dining Philosophers' Problem 448
Commercial Off-the-Shelf 28 Disassembler 597
Common Language Runtime 650 Distributed 73
Communicating Process Model 212 do 320
Communication Interface 45 do while 324
Competing Process 427 DS80C320 156
Compile Control 350 DS80C323 156
Compiler 319 Dynamic Memory 366
Complex Instruction Set Computing 22, 206 Dynamic RAM 32
Computational Engine 21
Computational Model 207 EDA 249
Computer Aided Design 616 EDLC 622
Computer Numeric Control 617 Electrically Erasable Programmable Read Only Memory 30
Conceptualisation 626 else 320
Concurrent Process Model 212 Embedded 'C' 319
Conditional Operator 323 Embedded firmware 59
canst 320, 35, Embedded Operating System 303
Constant data 352, 366 Embedded Systems 3, 72
Constant pointer 353 Characteristics 72
Context Retrieval 402 Large-Scale 7
Context Saving 402 Medium-Scale 7
Context Switching 121,402 Quality Attributes 74
continue 320 Small-Scale 7
Control DFG 207 Emulation 155
Controller Architecture 205 Encoder 234
Controller Area Network 87 enum 320
Cost Benefit Analysis 627 Erasable Programmable Read Only Memory 30
COTS 28,624 Events 475
Counter 126 Evolutionary Model 639
Counting Semaphore 463 Exception Handling 388
 Index

Execute in Place 34 High Level Language 313

extern 320,321 K,·
i.LINK 55 K1
Factory programmed chips 553 I/O System Management 383 Kt
FCFS 405 I/0 Unit 21
Feasibility Study 627 I2C 45 L· :,:·
(

Feature set 93 IAP 552 ' L,

FET 107 IC 243 u
Field Programmable Gate Array (FPGA) 15, 26 ICE 603 L,
File 350 IDE 548, 557, 587 u
File System Management 383 IDL 439 L(
Finite State Machine 208 IDLE Task 424 LI
Finite State Machine Datapath 205 IE 122 Ll
Firewire 55 IEEE 1394 55 Li
Finnware 4, 302, 548 if 320 LI
First Come First Served Scheduling 405 if else 322 Li
Flip-flop 238 In Application Progralllffiing 5'52 LI
D 239 In Circuit Emulator 603 Li
\
J-K 239 Incremental Model 638 \ Li
S-R 238 Infinite loops 355 Li
float 320 Infrared 56 Li
Footprint 267 InjectionMoulding' 618 Li
for 320,324 InlineAssembly 318 LI
Fountain Model 638 Instruction Set 164 Le
FPGA 26 In System Programming 112, 551 Le
FPSLIC 647
free 370
int 320
Integrated Circuit 243 f
t
Le
Le
FSM 208 Integrated Development Environment 587 Le
FSMD 205 Integration Testing 630, 633 Le
Full Duplex 139 Inter Integrated Circuit 45 101
Function Generator 608 InterlockedCompareExchange 460 Le
function pointer 337 Intennediate Language 650 Le
Functions 333 Interrupt 120, 360 L}
Fused Deposition Modelling 617 Interrupt Handling 389
Interrupt Service Routine 316 M
General Packet Radio Service 58 IrDA 56 M
General Purpose Operating System 386 ISP 112,551 M
General Purpose Processor 19 Iterative Model 638 m
Gerber File 286 M
global 366 J2ME 650 M
goto 320, 324 Java bytecode 649 M
GPOS 386 JavaME 650 M
GPP 19 Java Native Interface 650 M
GPRS 58 Java Thread 399 M
Java Virtual Machine 649 M
Hard Real-Time 390 JNI 650
Hardware Software Trade-offs 219 Job Queue 405
HCFSM 210 JTAG 551,608
HECU 86 Just In Time Compiler 649
HEXFile 594 NM 649
Intel HEX File 595
Motorola HEX File 596 Keil 558
Hierarchical/Concurrent 210 Kernel 382
High-speed Electronic Control Units 86 , Kernel Space 384
 Index
I

Kernel Thread 401 PROM 29

Keyboard 42 Memory Management 388
Keywords 320 Memory Mapped'0bjects. 4~
1 Memory Shadowing 33 \
Large-Scale Integration 243 memset 370
, _Last Come First Served Scheduling 407 Message Passing 433
· Latch 231 Message Queue 434
Layers 271 MicroC/OS-ll 470, 514
Layout Design 272 Counting Semaphore 529
LCFS 407 Interrupt Handling 540
LECU 86 Inter Task Communication 521
LED 36 Kernel functions 519
Library file 311 Mailbox 521
LIFO ,407 Memory Management 538
Light Emitting Diode 36 Message Queue 526
LIN 87 Mutex 530
Linear Model 636 Mutual exclusion 527
Linker 311 Task Creation 515
List File 589 Task Scheduling 520
Little-endian 24 Task Synchronization 527
Livelock 448, 449 Timing & Reference 538
LM7805 112 Microcontroller 6, 15, 19
Load Store Architecture 24 Microkemel 385
Local Interconnect Network Bus 87 Microprocessor 6, 15, 18
Locator 311 Million Instruction Per Second 93
Logical Operations 321 MIMD 206
Logic Analyser 608 MIPS 93
Logic Gates 231 mnemonics 306
long 320 Model 625
Looping Instructions 323 Monitor Program 602
Low-speed Electronic Control Units 86 Monitor ROM 602
Lynx 55. ' Monolithic Kernel 385
MOST 87
Machine Language 306 Motorola HEX 596
Macro 351 Moulding 617
Mailbox 438 MROM 29
malloc 368 MTBF 75
Map File .592 MTTR 75
MAX232 144 Multicore ~ocessors 647
Mean Time Betwe~n Failures 75 Multimeter 607
Mean Time To Repair 75 Multiple Instruction Multiple Data
Media Oriented System Transport Bus 87 Multiplexer 235
Medium-Scale Integration 243 Multiprocessing 401
Memory 17, 28 Multitasking 121,402, 403
RAM 30 Multithreading 393
DRAM 32 Mutex 467
NVRAM 32 Mutual Exclusion 446
SRAM 30 I
ROM 29 NA.ND FLASH 34
EEPROM 30 Need 625
EPROM 30 · Netlist 264
I
FLASH 30 Nqn-Operait~o.nal Quality Attributes
Masked ROM 29 Debug~abil1ty · 76
OTP 29 Ewjlyability 77
 Index

Portability 77 POSIX 502

Testability 76 POSIX Threads 395
Non-preemptive Multitasking 403 PPI 42
Non-preemptive Scheduling 405 Pre-processor 349
NORFLASH 34 Preemptive multitasking 403
freemptive Scheduling 412
Object-Oriented Model 213 Preemptive SJF Scheduling 413
Object File 592 Preliminary Design 630
Object Oriented Design 214 Preprocessor Output File 591
OCD 605 Primary Memory Management 383
offsetof 349 Princeton architecture 23
ORA 651 Printeq Circuit Board 64, 288
OMA 651 printf 331
ONCE 155 Priority Based Scheduling 410,420
On Chip Firmware Debugging 605 Priority Ceiling 455
Opcode 164,307 Priority Inheritance 454
Ope'n Collector 230 Priority Inversion 453
Open Handset Alliance 651 Process 391,392
Open Mobile Alliance 651 State 392 a
Openmoko 652 Process Control Block 393
Operand 164,307 Processing Elements 206
Operating System 305,382 Process Life Cycle 392
Operational Quality Attribute 74 Process Management 382,387, 393 I

Availability 76 Processor Architecture 23 '·

Confidentiality 76 Harvard 23
Integrity 76 Von-Neumann 23
Maintainability 75 Process Scheduling 387
Reliability 75 Proces&.S.ynchronisation 388
Response 75 Producer Consumer Problem 451
Safety 76 Product Enclosure 616
Security 76 Productivity 624
Throughput 75 Product Life Cycle 78, 625
Optocoupler 37 Product Re-engineering 626
Oscillator Unit 62 Product Support 634
Out-of-Circuit Programming 549 Programmable Logic Device 26
Programmable Peripheral Interface 42
Package 267 Programmable Read Only Memory 29
Packed structure 345 Program Memory 21
PCB 64, 288, 393 Progum1rojqg _g!ements 647
PCB Etching 290 Project Management 623
PCB Milling 290 Prototyping Model 639
PCB Printiµg 291 Pthreads 395
PIC 653 Push Button 41
Piezo Buzzer 41
Pipelining 25 Quasi Bi-directional 107
Pipes 427
Anonymous 428 Racing 443, 449
Named 428 R.Af4 30,344
PLD 26 Random Access Memory 30
Pointer 327 \ ' Rapid Prototyping. 616
Pointer to constant data 353 Re-entrant Functio11 3-64
Polling '120 \ · Reactive System 73
Portability 315 Read-Modify-Write 106
Portable threads 400 Readers-Writers Problem 453
 Read Latch 106 Silk Screen 291
ReadPin 106 SIMD"206
_ ~~ady Queue 405 Simulator 571,598
..Rea1-'.Iime 73,343,386 Single Instruction Multiple Data 206
RealeTime Clock (RTC) 62,389 sizeof 320
- Real-Time Kernel 387 SJF 108
realloc 370 Sleep · 355
Real Time Operating System 7,306,386 Sleep & Wakeup 462
Reconfigurable Processor 647 Small-Scale Integration 243
Reconfigurable SoCs 647 SoC 646
Recursive Function 362 Sockets 440
Reduced Instruction Set Computing 22, 206 Soft Real-Time 390
register 320,321 Solder Mask 291
Register Transfer Level 245 SPI 47,551
-.~ll~lational Operations 322 Spin Lock 457
Relay 40 Spiral Model 640
Remote Method Invocation 439 SRT 413
Remote Procedure Call 439 Stack 391
Requirem~nts' Analysis 628. Starvation 422, 448, 449
-~f Circuit 160 State Machine Model 208
Response Tim'e 404 static 320,321,335,366
j RET 124 Static Memory ~~6
Reti.rement 636 Static RAM 30
return 320 Stepper Motor 38
RISC 7, 22,206,646 Bipolar 38
RMI 439 . Half Stepping 39
ROM 29 Unipolar 38 /
-Room Temperature Vulcanised 617 Waye Stepping 39
Rimnd Robin Scheduling 414 Stereolithography 617
Routes 270 Storage Class 321
RPC 439 strcat 331
~-232 51, 144 strcmp 332
RS-422 53 strcpy 333
RS-485 53 stricmp 332
RSoC 7,648 String 330
RTC 62 strlen 332 ·
RTL 245 struct 320, 34-1
RTOS 386 structure 341
Structure padding 345
scanf 331 Super Loop 303
Schematic Desi&n 249 switch 320
Schmitt Trigger 128 switch case 323
f Selectivetaser Sintering 617
Semaphore: 463
')er
 .Index

Binding 401 Very Long Instruction Word 206

Many-to-One · 40 i VHDL 206, 245
One-to-One 40 I Via 271
Thread Pre-emption 400 Virtual Memory 388
Threads 393 VLIW 206
Thread Standard 394 VLSI 243
Thrqughput 404 void 320
Time Management 389 volatile 320, 353
Timer 126 volatile pointer 355
Timer tick 389 Von-Neumann 99
Time to Market 77, 204 VxWorks 470, 4991 648
Time to Prototype 77 Binary Semaphore 509
Toggling Bits 358 Counting Semaphore 509
Tooling 617 InterruptHandling 51 l
Tri-State 230 Interrupt Locking 509
Truth Table 236 Inter Task Communication 503
TSL 459 . Kernel Service 503
TTL Logic I06 Message Queue 503
Turnaround Time 404 Mutual Exclusion 508
)ypedef 320,342,348 Mutual exc!usion Semaphore 509
Pipes 507
UART_ 48 Signals 507
UL_N2803 II 5 Tusk Creation 499
UML 214,218 Task Locking 508
Activity diagram 219 Task Scheduling 502
Collaboration 218 Task Synchronisation 508
Sequence-diagram 218
State Chart diagram 219 Waiting Time 404
Use Case diagram 218 Watchdog Timer 63
Unified Modelling Language 214 Waterfall Model 636
union 320, 348 w.hile 320, 324
Unit Testing 630, 633 while continue 324
Universal Asynchronous Receiver 1.hf_nsmitter 48 Wt-Fi 57
Universal SeriaLBus 53 · Win32 Thread 397
unsigned 320 wind 499
Upgrades 635
USB 53 XIP 34
User Acceptance Testing 630
User Level Thread 401 Zig~ee 58
User Space 384 ZigBee Coordinator 58
ZigBee End Device 58
ZigBee Router 58
Introduction· to
JEMBEDDED
SYSTEMS
Meant for students and practicing engineers, this
book provides a comprehensive introduction to the
design and development of embedded hardware and
firmware, their integration, and the management of
embedded systE:m development process.

Salient features
>- Follows a design-oriented approach
>- Detailed coverage of RTOS internals, multitasking,
task management, task scheduling, task
communication and synchronisation
>- In-depth elucidation of the internals of
MicroC/ OS-II and VxWorks RTOS kernels
>- Practical implementation using real-life examples of
Washing Machine, Automotive, Stepper Motor, and
Mobile Phones
>- Deals in embedded C, delving into basics and
unraveling advanced level concepts
>- Pedagogy
♦ 433 Review questions
♦ 428 Objective-type questions
♦ 25 Examples
♦ 80 Lab assignments

URL: http://www.mhhe.com/shibu/esle

ISBN-13: 978-0-07-01~589-~
ISBN-10: 0-07-01~589-X

Il l Higher
I Education 9 780070 145894
1111