In-House Practical Training Report

On
Embedded Systems


Submitted to
Amity School of Engineering and Technology




GUIDED BY: SUBMITTED BY:
Sangeeta Rani Sudhanshu Kumar Chandra
Asst. Professor A2305212428
CS&E Department 5CSE-6 (X)

Candidates Declaration

I Sudhanshu Kumar Chandra student of B.Tech (CSE) hereby declare that the project titled
Embedded Systems which is submitted by me to The Department of Computer Science,
Amity School of Engineering and Technology, Amity University Uttar Pradesh, Noida, in partial
fulfillment of requirement of award of the degree of Bachelor of Technology in Computer
Science, has not been previously formed the basis for the award of any degree, diploma or other
similar title or recognition.




Signature
Sudhanshu Kumar Chandra
(A2305212428)




Acknowledgement
I take immense pleasure in thanking the people who helped me in the completion of my In-
House Training and the project associated with it.
My sincere thanks goes to my mentor maam Sangeeta Rani and Program Leader, sir Praveen
Kumar for guiding and correcting me with attention and care. I greatly thank them for the
efforts they took to help me complete the project.
I also express my thanks to Prof. (Dr.) Abhay Bansal, The Head Of Department (HOD), for
extending their support.
Words are inadequate in offering my thanks to the various helpful people of Amity University
for their encouragement and cooperation in carrying out the project work.
I would also thank my Institution and my faculty members without whom this project would
have been a distant reality.
Finally, yet importantly, I would like to express my heartfelt thanks to my beloved parents for
their blessings, my friends/classmates for their help and wishes for the successful completion of
this project.

Sudhanshu Kumar Chandra
A2305212428
CSE, ASET NOIDA






Certificate
This is to certify that Mr. Sudhanshu Kumar Chandra, student of B. Tech. in Computer
Science has carried out the work presented in the project of the Practical Training-I entitled
Embedded Systems as a part of Second year program of Bachelor of Technology in Computer
Science from Amity School of Engineering and Technology, Amity University, Noida, Uttar
Pradesh under my supervision.


Sangeeta Rani
Asst. Professor















Abstract
Embedded Systems are systems which consist of a computer program and it is dedicated for a
specific purpose. The use Embedded systems is very wide spread today. This project is a result
of course taken on Embedded Systems on EdX which is provided by University of Texas,
Austin. The Course covered several quizzes and Labs and finally a project which is the base of
this project report. The labs consisted of several other smaller projects as well like robot
designing, interrupts etc. The course comprised of comprised of several modules to be completed
over 10 weeks. Each module consisted of small lecture videos along with the text. There was no
textbook defined for the course. At the end of each module there was lab to implement the topic
studied. The TM4C123 Tiva Launchpad from Texas Instruments has been used for the course. It
also included some extra electronics such as proto board, LEDs, potentiometer, some resistors.
An optional LED Graphics Display was also used. Embedded systems are going to be the future
of our todays everyday objects. They are going to become an integral part of our living and have
somewhat started being so. This course helped in understanding the programming and various
features of ESs and how to apply them in real life application.










Table of Contents
S. No Description Page No.
1. Introduction 4
2. Multimeter An example of embedded system 5
3. Device Driver 6
4. ARM Cortex M4 Architecture 7
5. Input/ Output Ports 9
6. CPU Registers 12
7. Address Space 13
8. Finite State Machine 14
9. Traffic Controller 17
10. Conclusion 21
11. References 22

















List of figures

S. No Description Page No.
1. Working of an Embedded System 4
2. Digital Multimeter - A typical embedded system 5
3. The basic components of a von Neumann computer include
processor, memory and I/O
7
4. A microcontroller is a complete computer on a single chip 8
5. Harvard architecture of an ARM Cortex-M-based
microcontroller
8
6. Assembly Language and C Developement Process 9
7. Architecture of TM4C123 microcontroller 10
8. Registers on the ARM Cortex-M processor 11
9. The program status register of the ARM Cortex-M processor 11
10. Microcontroller Used in the course 12
11. Memory map of the TM4C123 14
12. Output of a Moore and a Mealy machine 16










INTRODUCTION
Embedded systems are systems which comprises of components and interfaces which are
connected together for a specific and common purpose. For example, the pacemaker. It is a
device which is used to maintain a constant heart beat rate. The chemical devices connected to
the pacemaker provide input to the device which is then processed in real time and the output is
provided as required.
In order to understand the term embedded microcomputer system, let us break the term and
consider each word separately.
In this context, the word embedded means something hidden inside so that no one can see it.
The term micro means small, and the word computer implies something that contains a
memory, processor and a means to exchange data with the external world. The word system
means multiple components interfaced together for a common purpose. Systems have structure,
behavior, and interconnectivity operating in a framework bound by rules and regulations.

Figure 1. Working of an Embedded System
Above figure shows how an embedded system works and interacts with the external
environment. The Microcontroller, TM4C in this case, consists of a processor, RAM, ROM and
I/O ports. ROM is used for storing the fixed constant data and the software and RAM is used for
storing temporary information in an embedded system. Flash EEPROM (electrically-erasable
programmable ROM) is used in many microcontrollers. This is because the information can be
easily erased and reprogrammed. These components are connected with a common bus. This
microcontroller interacts with other electrical, mechanical, chemical or optical devices using the
I/O port. I/O ports have the ADC (Analog to Digital Converter). It means external devices send
the analog signal to microcontroller which is then converted to digital signal to be processed.
Similarly, when information is sent to theses external devices, it is in digital form and is
converted to analog signal by the DAC (Digital to Analog converted). The way in which humans
interact with the device is often called the human-computer interface (HCI) or man-machine
interface (MMI). This is how the embedded systems work.

MULTIMETER an example of Embedded System
A digital multimeter is a typical example of an embedded system. The system consists of a rotary
dial for input and two probes (red and black). The output is given on a LCD screen. The black
chip inside the multi meter is the microcontroller and its ROM is specifically programmed to
measure the resistance, voltage and the current. As it can be seen from the figure there is not
much inside the system other than the components described above. The device is powered by a
battery.

Figure 2. Digital Multimeter - A typical embedded system


Device Driver
There are software programs that let us access the I/O ports. Stellaris microcontrollers have a
number of I/O ports. One of the simplest ports of these is the parallel port or General Purpose
Input/output (GPIO) Port. One such parallel port is Port A. The software will refer to this port as
GPIO_PORTA_DATA_R. Ports are a collection of pins, usually 8, which can be used for either
input or output. If Port A is an input port, then when the software reads from the port A
(GPIO_PORTA_DATA_R) , it gets eight bits (each bit is 1 or 0), representing the digital levels
(high or low) that exist at the time of the read. If Port A is an output port, then when the software
writes to GPIO_PORTA_DATA_R, it sets the outputs on the eight pins high (1) or low (0),
depending on the data value the software has written. This is the way device drivers work.
Some of the properties of embedded systems are as follows:
Small size and weight
Run in real time
High volume, low cost
A microcontroller hidden inside
A dedicated purpose
Input/output is important
Extremely reliable
Low power




ARM CORTEX M4 architecture

Figure 3. Basic components of a von Neumann computer include processor, memory and
I/O
The microprocessor consists of a Processor, RAM and ROM. RAM is used to process and handle
them in real time. They are connected to the input and output ports with three different buses.
The first one is the address bus, the second is the Data and the third is the control. These buses
act as a link between the components and the ports and perform the respective tasks.
The input output ports are connected to the external circuits. These circuits consists of resistors,
LEDs and other components needed to make up the task that the microcontroller is programmed
to do. The external circuits in turn are connected to the physical devices. These physical devices
provide the external data to the microcontroller in analog signals which is then converted into
digital signals by the ADC.


Figure 4. A microcontroller is a complete computer on a single chip.
The computer can store information in RAM by writing to it, or it can retrieve previously stored
data by reading from it. RAMs are volatile; meaning if power is interrupted and restored the
information in the RAM is lost. Most microcontrollers have static RAM (SRAM) using six
metal-oxide-semiconductor field-effect transistors (MOS or MOSFET) to create each memory
bit. Four transistors are used to create two cross-coupled inverters that store the binary
information, and the other two are used to read and write the bit.

Figure 5. Harvard architecture of an ARM Cortex-M-based microcontroller.



Figure 5 shows a simplified block diagram of a microcontroller based on the ARM Cortex-
M processor. It is Harvard architecture because it has separate data and instruction buses. The
Cortex-M instruction set combines the high performance typical of a 32-bit processor with high
code density typical of 8-bit and 16-bit microcontrollers. Instructions are fetched from flash
ROM using the ICode bus. Data are exchanged with memory and I/O via the system bus
interface. On the Cortex-M4 there is a second I/O bus for high-speed devices like USB. There
are many sophisticated debugging features utilizing the DCode bus. The nested vectored
interrupt controller (NVIC) manages interrupts, which are hardware-triggered software
functions. Some internal peripherals, like the NVIC communicate directly with the processor via
the private peripheral bus (PPB). The tight integration of the processor and interrupt controller
provides fast execution of interrupt service routines (ISRs), dramatically reducing the interrupt
latency.

Figure 6. Assembly Language and C Developement Process
All the programs for the course will be developed in C Language. The Source code will be first
edited on the Keil u Vision editor. It will then be built into object code which will consist of
addresses and the data in the program. The next step is to debug the program in a simulated
microcontroller. This will produce the same output as the real board. It is now that we download
the programs object code in to the memory of the real microcontroller and debug it.

Input/Output Ports

Figure 7. Architecture of TM4C123 microcontroller.
The microcontroller has six general purpose input output ports which are named as GPIO Port A,
GPIO Port B, GPIO Port C, GPIO Port D, GPIO E and GPIO F. All the ports have different input
and outputs as mentioned in the figure. It has a 32k RAM. The ports have different number of
pins that enable the communication. All the ports are connected through a system bus. It
provides a common connection to all the ports in the microcontroller.



CPU Registers

Figure 8. Registers on the ARM Cortex-M processor.
Registers are high speed storage inside processor. The CPU of the micro controller consists of
thirteen general purpose registers (R0-R12) and three special purpose registers (R13-R15). Three
special purpose registers are stack pointer, link register and program counter. R0-R12 are general
purpose registers and can contain either data or address. Stack Pointer (R13) points to top
element on the stack. Link Register (R14) is used to store return location for functions. Program
counter (R15) points to next instruction to be fetched from memory.

Figure 9. The program status register of the ARM Cortex-M processor

The ARM Architecture procedure call standard, AAPCS, part of the ARM Application Binary
Interface (ABI), uses registers R0, R1, R2, R3 to pass input parameters to a C function. Also
according to AAPCS, we place the return parameter in register R0.
In this course, SP will always be Main Stack Pointer and not the Process Stack pointer.
There are three status registers named
Application Program Status Register (APSR)
Interrupt Program Status Register (IPSR)
Status Program Status Register (EPSR)
These register are shown in figure 9. They can be accessed individually or in combination as
Program Status Register (PSR).

Figure 10. Microcontroller Used in the course

Address Space
All LM3S and TM4C microcontrollers have a Cortex-M processor. There are hundreds of
members in this family; some of them are listed in below.
Part number RAM Flash I/O I/O modules
LM3S811 8 64 32 PWM
LM3S1968 64 256 52 PWM
LM3S2965 64 256 56 PWM, CAN
LM3S3748 64 128 61 PWM, DMA, USB
LM3S6965 64 256 42 PWM, Ethernet
LM3S8962 64 256 42 PWM, CAN, Ethernet, IEEE1588
LM4F110B2QR 12 32 43 floating point, CAN, DMA
LM4F120H5QR 32 256 43 floating point, CAN, DMA, USB
TM4C123GH6PM 32 256 43 floating point, CAN, DMA, USB, PWM
KiB KiB Pins
Memory and I/O modules (all have SysTick, RTC, timers, UART, I
2
C, SSI, and ADC).
The memory map of TM4C123 is illustrated in Figure 2.18. Although specific for the TM4C123,
all ARM Cortex-M microcontrollers have similar memory maps. In general, Flash ROM
begins at address 0x0000.0000, RAM begins at 0x2000.0000, the peripheral I/O space is from
0x4000.0000 to 0x5FFF.FFFF, and I/O modules on the private peripheral bus exist from
0xE000.0000 to 0xE00F.FFFF. In particular, the only differences in the memory map for the
various 180 members of the LM3S/TM4C family are the ending addresses of the flash and RAM.
Having multiple buses means the processor can perform multiple tasks in parallel. The following
is some of the tasks that can occur in parallel
ICode bus Fetch opcode from ROM
DCode bus Read constant data from ROM
System bus Read/write data from RAM or I/O, fetch opcode from RAM
PPB Read/write data from internal peripherals like the NVIC
AHB Read/write data from high-speed I/O and parallel ports (M4 only)

Figure 11. Memory map of the TM4C123.

Finite State Machine
Software abstraction allows us to hide the details of implementation from what the software
does. If we build our software using the abstract building blocks then we can understand the
problem and the solution well. This helps us in the separation of the policies and the mechanisms
of the software.
The abstraction principal that I have used in here is Finite State Machines (FSM). FSMs have
input outputs and the states which defines where the system currently is. With FSMs we can
build a time dependent relationships between the inputs and the state. If the problem is mapped
into a state transition graph, then we can easily understand, modify and debug the system.
FSM is an abstraction principle which gives us the solution of our problem like an algorithm. But
unlike an algorithm which follows a sequence of steps to come to a solution, a FSM gives us the
solution in the form of behavior of the system. It gives the state of the system for the given input
(which is the solution of the problem).

Listed below are the components of a Finite State Machine. A FSM can be described using these
five elements.
1. A finite set of states a FSM has a finite number of states that the system can be in at any
given point of time. The current state of the system depends on the input given to the
system. It is to be noted that a FSM could be in one and only one of the states at a time.
2. A finite set of inputs a FSM has finite number of inputs that come from outside the
system. An input to the system leads to a change in state which is described by the state
transition graph.
3. A finite set of outputs a FSM has a number of outputs that the system generates in
response the input and the current state.
4. A transition function a FSM describes all the transition functions which tell the next
state of the system depending upon the input and the state.
5. Specification of how outputs are determined There are two ways by which output of the
system can be determined. Either output can be function of both input or the current state
or it can be a function of just the current state.
Mathematically, it can be described be these two functions,
( )
()
A system that follows the first function is called Mealy machine and a system following
the second function is called Moore machine.
I will implement the FSM using table data structure. There is a 1-1 mapping between the
elements of the FSM and the table.
In order to design a FSM, first we describe what constitutes a state. In the system that I am going
to develop, the one-way traffic controller, a state might simply mean the combination of lights
that are ON during a particular state. Then we will consider all the possible states that the system
could go to. In all the systems, there has to be an output that can give out information to the
environment and input that can receive information from its environment.


A Moore system is going to go over these steps over and over again
1. Produce an output depending on the current state
2. Wait for a certain amount of time (optional)
3. Take the input
4. Make transition to next state depending upon input and current state
An example of a state in a state transition graph is shown below. The circle denotes a state. It has
a symbolic name and below it are the output and the wait time. The arrow points to the next state
if the input marked on the arrow is received by the system. Difference between a Mealy and
Moore machine is that output in Mealy machine is dependent on the input from which the system
arrived in present state and Moore machine does not.

Figure 11. Output of a Moore and a Mealy machine
Traffic signal controller
System Requirements

Consider a 4-corner road intersection as shown in the above figure. There are two one-way
streets which are labeled South (cars travel South) and West (cars travel West). There are three
inputs to the LaunchPad, two are car sensors, and one is a pedestrian sensor. The South car
sensor will be ON if one or more cars are near the intersection on the South road. Similarly, the
West car sensor will be ON if one or more cars are near the intersection on the West road. The
Walk sensor will be ON if a pedestrian is present and he or she wishes to cross in any direction.
In this simple system, if the walk sensor is ON, there is pedestrian to service, and if the walk
sensor is OFF, there are no people who wish to walk. In a similar manner, when a car sensor is
OFF, it means no cars are waiting to enter the intersection. The implementation will need 6
LEDs that represent the two Red-Yellow-Green traffic lights to produce the output. I will use the
PF3 green LED for the walk light and the PF1 red LED for the dont walk light. When the
walk condition is signified, pedestrians are allowed to cross. When the dont walk light
flashes (and the two traffic signals are red), pedestrians should hurry up and finish crossing.
When the dont walk condition is on steady, pedestrians should not enter the intersection.
Solution
I have chosen following GPIO as the output ports
Red West PB5
Yellow West PB4
Green West PB3
Red East PB2
Yellow East PB1
Green East PB0
Walk PE3
Dont walk PE1
The input sensors are going to be on the following GPIOs
Walk sensor PE2
North/South sensor PE1
East/West sensor PE0
A state in the system is going to contain the output, the waiting time in the state and the next
states to transition upon new input. So we declare the structure defining the state as:
struct State {
unsigned long ortB_out;
unsigned long ortF_out;
unsigned long Time;
unsigned long Next[8];};

At any given time, the system can in any of the following states:
goW 0
waitW 1
goS 2
waitS 3
walk 4
hurry1 5
hurry2 6
hurry3 7
hurry4 8
hurry5 9
hurry6 10
dontWalk 11

The Moore Cycle mentioned above can be achieved by looping infinitely through following lines
GPIO_PORTB_DATA_R = FSM[S].PortB_out; // set PB5-0 (LED o/p)
GPIO_PORTF_DATA_R = FSM[S].PortF_out; // set PF3 and PF1 (LED
o/p)
SysTick_Wait10ms(FSM[S].Time);
Input = GPIO_PORTE_DATA_R&0x07; // Read PE2-0
S = FSM[S].Next[Input];























Program
// ***** 0. Documentation Section *****
// TableTrafficLight.c for Lab 10
// Runs on LM4F120/TM4C123
// Index implementation of a Moore finite state machine to
operate a traffic light.
// Sudhanshu Kumar Chandra
// June 27, 2014

// east/west red light connected to PB5
// east/west yellow light connected to PB4
// east/west green light connected to PB3
// north/south facing red light connected to PB2
// north/south facing yellow light connected to PB1
// north/south facing green light connected to PB0
// pedestrian detector connected to PE2 (1=pedestrian present)
// north/south car detector connected to PE1 (1=car present)
// east/west car detector connected to PE0 (1=car present)
// "walk" light connected to PF3 (built-in green LED)
// "don't walk" light connected to PF1 (built-in red LED)

// ***** 1. Pre-processor Directives Section *****
#include "TExaS.h"
#include "tm4c123gh6pm.h"

// ***** 2. Global Declarations Section *****

//LINKED DATA STRUCTURE
struct State {
unsigned long PortB_out;
unsigned long PortF_out;
unsigned long Time;
unsigned long Next[8];};
typedef const struct State STyp;
#define goW 0
#define waitW 1
#define goS 2
#define waitS 3
#define walk 4
#define hurry1 5
#define hurry2 6
#define hurry3 7
#define hurry4 8
#define hurry5 9
#define hurry6 10
#define dontWalk 11


STyp FSM[12]={
{0x0c,0x2,50,{goW,goW,waitW,waitW,waitW,waitW,waitW,waitW},
{0x14,0x2,30,{goS,goW,goS,goS,walk,walk,walk,goS}},
{0x21,0x2,50,{goS,waitS,goS,waitS,waitS,waitS,waitS,waitS},
{0x22,0x2,30,{walk,goW,goS,goW,walk,walk,walk,walk}},
{0x24,0x8,50,{walk,hurry1,hurry1,hurry1,walk,hurry1,hurry1,hurry
1}},
{0x24,0x2,10,{hurry2,hurry2,hurry2,hurry2,walk,hurry2,hurry2,hur
ry2}},
{0x24,0x0,10,{hurry3,hurry3,hurry3,hurry3,walk,hurry3,hurry3,hur
ry3}},
{0x24,0x2,10,{hurry4,hurry4,hurry4,hurry4,walk,hurry4,hurry4,hur
ry4}},
{0x24,0x0,10,{hurry5,hurry5,hurry5,hurry5,walk,hurry5,hurry5,hur
ry5}},
{0x24,0x2,10,{hurry6,hurry6,hurry6,hurry6,walk,hurry6,hurry6,hur
ry6}},
{0x24,0x0,10,{dontWalk,dontWalk,dontWalk,dontWalk,walk,dontWalk,
dontWalk,dontWalk}},
{0x24,0x2,0,{goW,goW,goS,goW,walk,goW,goS,goW}}};

//GLOBAL VARIABLES
unsigned long S; // index to the current state
unsigned long Input;

// FUNCTION PROTOTYPES: Each subroutine defined
void DisableInterrupts(void); // Disable interrupts
void EnableInterrupts(void); // Enable interrupts
void SysTick_Init(void);
void SysTick_Wait(unsigned long);
void SysTick_Wait10ms(unsigned long);
void PLL_Init(void);
// ***** 3. Subroutines Section *****

// Initialize SysTick with busy wait running at bus clock.
#define NVIC_ST_CTRL_R (*((volatile unsigned long
*)0xE000E010))
#define NVIC_ST_RELOAD_R (*((volatile unsigned long
*)0xE000E014))
#define NVIC_ST_CURRENT_R (*((volatile unsigned long
*)0xE000E018))

void SysTick_Init(void){
NVIC_ST_CTRL_R = 0; // disable SysTick during
setup
NVIC_ST_CTRL_R = 0x00000005; // enable SysTick with core
clock
}
// The delay parameter is in units of the 80 MHz core clock.
(12.5 ns)
void SysTick_Wait(unsigned long delay){
NVIC_ST_RELOAD_R = delay-1; // number of counts to wait
NVIC_ST_CURRENT_R = 0; // any value written to CURRENT
clears
while((NVIC_ST_CTRL_R&0x00010000)==0){ // wait for count flag
}
}
// 10000us equals 10ms
void SysTick_Wait10ms(unsigned long delay){
unsigned long i;
for(i=0; i<delay; i++){
SysTick_Wait(800000); // wait 10ms
}
}


int main(void){ volatile unsigned long delay;
TExaS_Init(SW_PIN_PE210, LED_PIN_PB543210); // activate grader
and set system clock to 80 MHz
EnableInterrupts();
SysTick_Init(); //SysTick Iniit

SYSCTL_RCGC2_R |= 0x32; // 1) B E F
delay = SYSCTL_RCGC2_R; // 2) no need to unlock

GPIO_PORTE_AMSEL_R &= ~0x07; // 3) disable analog function
on PE2-0
GPIO_PORTE_PCTL_R &= ~0x00000FFF; // 4) enable regular GPIO
GPIO_PORTE_DIR_R &= ~0x07; // 5) inputs on PE2-0
GPIO_PORTE_AFSEL_R &= ~0x07; // 6) regular function on PE2-
0
GPIO_PORTE_DEN_R |= 0x07; // 7) enable digital on PE2-0

GPIO_PORTB_AMSEL_R &= ~0x3F; // 3) disable analog function
on PB5-0
GPIO_PORTB_PCTL_R &= ~0x00FFFFFF; // 4) enable regular GPIO
GPIO_PORTB_DIR_R |= 0x3F; // 5) outputs on PB5-0
GPIO_PORTB_AFSEL_R &= ~0x3F; // 6) regular function on PB5-
0
GPIO_PORTB_DEN_R |= 0x3F; // 7) enable digital on PB5-0

GPIO_PORTF_AMSEL_R &= ~0x0A; // 3) disable analog function
on PB5-0
GPIO_PORTF_PCTL_R &= ~0x0000F0F0; // 4) enable regular GPIO
GPIO_PORTF_DIR_R |= 0x0A; // 5) outputs on PB5-0
GPIO_PORTF_AFSEL_R &= ~0x0A; // 6) regular function on PB5-
0
GPIO_PORTF_DEN_R |= 0x0A; // 7) enable digital on PB5-0

S = goW;
while(1){
GPIO_PORTB_DATA_R = FSM[S].PortB_out; // set PB5-0 (LED
o/p)
GPIO_PORTF_DATA_R = FSM[S].PortF_out; // set PF3 and PF1
(LED o/p)
SysTick_Wait10ms(FSM[S].Time);
Input = GPIO_PORTE_DATA_R&0x07; // Read PE2-0
S = FSM[S].Next[Input];
}
}

Debugging using simulator
The program is first built into object code by selecting the use simulator in debug tab of select
target menu. Next the debugging session is started by selecting start/stop debugging session from
Debug menu. The debugging session starts with the Traffic Hardware and the Port F hardware
and registers menu. Start the code execution by pressing the Run button. The code starts
executing and the traffic controller is now functional. The switch for North/South, East/West and
Walk can be pressed to see the combination of lights ON for any input.
Debugging using real board
The circuit for the system is assembled on the proto-board using switches, registers and
male/female wires. Change the debugging option from



Conclusion
Embedded systems have a far reaching application than we know about it today. We are
surrounded by computers and the kind of devices that these computers are embedded into have
become an integral part of our lives and we fail to realize the importance that the posses. Today,
it is used by almost every industry and its use will continue to grow over time. This is because a
computer sitting in my desk is not as useful to as a device that interacts with the physical
environment and gives me the desired result.
The objective of this course was to learn the principles behind Embedded systems and its
application. The course was provided on EdX, an online learning platform which provides free
courses from the best universities of the world to anybody with an access to internet. This course
on embedded system was provided by University of Texas, Austin. The course helped me
achieve its objectives.
The game that I have developed as a final project in the course is just an application of what I
have learnt and I would like to take this learning forward and develop on to it. The mail focus of
the class was on the input/output performed on the microcontroller.
Moreover, I had the opportunity to use equipments such as a voltmeter, logic analyzer, and
oscilloscope. Some other debugging techniques that I used included heartbeats, single stepping
etc. one of the most powerful debugging techniques that I learnt is to connect unused ports to a
scope so that I can profile my real time system.





References
Edx. (2014, May 03). Embedded Systems. Retrieved May 03, 2014, from Edx: www.edx.org
Mano, M. M. (2012). Computer System Architecture. Pearson Education.
Stallings, W. (2010). Computer Organisation and Archiecture. Prentince Hall.
Volvano, J. (2010). Embedded Systems UTx. Retrieved July 15, 2014, from University of Texas
at Austin: http://users.ece.utexas.edu
Volvano, J. (2014). Real-Time Interfacing to ARM Cortex-M Microcontrollers. Chicago.