Embedded System and Embedded Controllers.pptx

Current Challenges in Embedded Systems,RTOS
AND ARM7 REAL TIME APPLICATIONS

DEFINITION OF EMBEDDED SYSTEMS AND DIMENSIONS
 Over the history, many definitions for embedded systems have been given, however,
they are all somewhat different.
 First study some of the existing definitions.
 Then we briefly look at the evolution of embedded systems from the introduction of
first microprocessors to the future distributed networked embedded systems.
 Based on earlier definitions and short historical analysis define and characterize
modern embedded systems in general.
 The historical classification of processor architecture generations, or computer
generations, is a topic that scientists and researchers easily debate on.
 Stallings (1996) suggests that there have been five generations of computers.

 The first three generations of these
• (vacuum tube computers 1946-1957,
• transistor circuit computers 1958-1964,
• integrated circuit (IC) computers 1965-1971) are agreed.
 According to Stallings, the division between the fourth and fifth generation is not clear,
although the generation is suggested to have changed with the shift from large scale
• Integration (LSI) based circuit technology (1972-1977)
• to very large scale integration (VLSI) based circuit technology (1978 onwards).
 Tanenbaum (1999) more or less agrees with the first three generations mentioned above,
although he defines the third generation to be the combination of Stallings’ generations 3
and 4 (IC and LSI).
 Tanenbaum defines the fourth generation to have begun in 1980 in the form of VLSI
based computers. In addition, he defines an additional generation, called the zeroth
generation for mechanical computers (1642-1945).

EVOLUTION OF EMBEDDED SYSTEMS
 Throughout the history, embedded systems have been designed around a central
master processing element.
 Representing one of the aforementioned generations of computer architecture:
starting from microcontrollers in the early age of embedded systems and
 Reaching multi-processor systems-on-chip (MPSoC) of the current implementations,
and in the near future networked MPSoCs as seen in Figure 1.
 In the 1980s, microcontrollers gained popularity as programmable single-chip and
stand-alone systems with very versatile built-in peripherals that provided an
integrated solution for many simple controlling tasks.
 Besides these controlling tasks, during the 1990’s there was an increasing need for
much heavier processing.

 For example, in cellular phones many algorithms were implemented using embedded
signal processor cores.
 Embedded systems were no longer individual microprocessor or microcontroller chips,
but merely cheap low-power embedded processor cores that could be integrated into
the same chip or package during the end-product manufacturing.

 In the 2000’s, the emphasis started to move towards much heavier processing with
multicore processors and complex field-programmable gate arrays.
 Incorporating embedded core processors and memories in addition to reconfigurable
logic facilities.
 These platforms accelerated the change from Single Processor System-on-Chips
(SPSoC) to Multi-Processor System-on-Chips (MPSoC).
 Mobile systems using MPSoC solutions as the processing platform, and the highly
improved communication capacity and access of today are paving the way towards
the next step in the evolution of embedded systems:
 network-connected and
 network-distributed co-operative embedded systems
based on MPSoC processing technology.

 “An embedded system has one or more programmable processing engines. The
engines operate as an independent stand-alone system either in the role of a
master or a slave and interact with their environment”.
DERIVATION OF CHALLENGES IN EMBEDDED SYSTEMS

 The implementations of future nanoscale electronic systems can be based either on
advanced CMOS-style technologies ranging between 0.1 – 0.05 µm, or completely
new, emerging technology approaches.
 In either case, the strategic issue is scalability towards and beyond gigascale
integration in three domains:
a. Architectural and system scalability with respect to complexity,
b. Performance scalability with respect to geometrical scaling in underlying device and
circuit structures, and
c. Design effort scalability with respect to increased functionality.
 Very high-speed access networks approaching gigabit speeds and providing
continuous network access provide also a new dimension to system scalability.

CHALLENGES
 The new challenges faced by developers of future complex converged wireless systems
can only be met by
• Adventurous development of technologies and
• Technological exploration and
• Experimentation of systems and system design methodologies.
 Research results from the areas of
• embedded system design,
• communication system design,
• system-wide security and hardware-software co-design
need to be brought together to produce multidisciplinary results that converge into novel
technologies usable in future secure embedded communication systems.

 The new challenges of
• device interoperability,
• self-awareness and
• embedded security
are a well advised starting point for studying and analysing the changes happening in the
design process of embedded systems.
Device Interoperability
 The device interoperability problem can be seen as a very simple and straightforward
issue: a system is composed of several subcomponents and they all should work on
several platforms.
 However, it has been a very complicated problem for system designers in embedded
and electronic system design already for two decades.
 HDL based macro libraries and synthesis tools made technology independence a very
important topic in hardware design in the early 1990’s.

 In networked embedded systems the components can be distributed to separate nodes
(independent networked devices) within a multi-standard communication infrastructure.
Self-Aware Autonomous Agent Based Systems
 A self-aware system is monitoring its environment and its own state in order to
optimize and match its functions to each situation.
 The key aspects of a self-aware system are presented in Figure 2.

 A system needs to monitor the state and the operation of its neighbouring systems, the
condition of its own hardware and the applications running on it.
 Based on monitored information and objective functions given, it supervises the
processing and the execution of the application.
 Key objective functions for today’s embedded systems can be seen as dependability,
ecology and scalability.
 Dependability means that the system should work in a robust manner under possible
hardware or software errors before, during and after reconfiguration, system and
platform changes.
 Ecology means concepts like power consumption, product life-time and R&D costs.
 Power consumption minimization is mostly finding the most power efficient implementation
for each particular phase of operation, dynamic system or subsystem shutdowns and

EMBEDDED SECURITY
 System and communication security is in the heart of the trends of having the ability to
connect a single device to multiple networks.
 That differ significantly from each other and on the other hand having small hand-held
devices that automatically try to establish network connections whenever they detect a
network service is available.
 The third dimension to embedded security challenges for future devices is protection
of the on-board data transfer system from attacks.
VERIFICATION AND MODELING
 In order to match the challenges described in the previous sections it is essential to
study them in more detail in relation to practical system design aspects.
 The target in self-awareness design is to build into the system the ability to
optimize and match its functionality dynamically to each situation.
 In practice this means that self-design principles need to be adopted. The self-
design approach is presented in Figure 3.

 Verification of modern embedded communication systems is a tedious task.
 The verification gap, i.e. the gap between design capacity (functional complexity) and
ability to verify, is getting larger and larger.
 The more parallel and heterogeneous the system is the more difficult the verification
process becomes.
 Traditional simulation based verification methods rely on stimulus sets which exercise the
functionality of a system model at different abstraction levels of interest.

 To reach an acceptable simulation (or test) coverage for a complex embedded system
with a very large number of possible behavioural scenarios.
 A vast number of possible individual system states is a cumbersome process, taking much
more time than the actual design phases.
Physical analysis of mutual effects

 Physical design issues, like cross-talk noise in communication links, clocking structures,
power distribution networks and
 Their noise, and technological variations in wires and components have been thoroughly
studied during the last twenty years (Bakoglu, 1990; Zheng et al. 2001).
 The vital issues are their mutual and accumulated effects, which are still mostly unknown
issues (Figure 4).
 Only some preliminary studies have been published so far (for example Tuuna, Nigussie
et al., 2008; Tuuna, Zheng et al., 2008).
 As the number of critical parameters needed in physical analyses is increasing heavily,
the models are changing towards analytical and system level models.
 As technological tolerances and their impact on system functionality and performance
seem to increase, the self-design approach is almost a necessity to make systems function
as specified from the very beginning.
 This includes moving from the fully synchronous domain towards asynchronous, self-timed
operations, which makes system testing and verification a more time-consuming task.
 In the link level, adjustable drivers and techniques need to be used.

SYSTEM IMPLEMENTATION PLATFORM
 In embedded system design, the second key area to be dealt with is the system
implementation platform including the firmware controlling the hardware.
 There the focus is the firmware layer added above the current embedded networks-
on-chip (NoC) platform layer as presented in Figure 5.

AN AGENT ABSTRACTION WITHIN A PLATFORM

 In general, an agent function together with an application function forms the component
abstraction that interacts with the underlying IC environment through simple diagnostic
and control devices and circuits.
 Self-awareness and the related models and monitoring techniques are the most critical
issue in the process.
 In our case, this model includes a mechanism for adding dynamic reconfigurability
properties to application abstraction, and further includes technology platform-level
information for the physical refinement process.
 After initial design of the system, reconfiguration is needed for three purposes:
capacity enhancement of system, fault-tolerance and possible online changes (system
upgrades) in specification.
 Autonomous behaviour will be created by combining the control abstraction and
reconfigurability capacity to handle the dynamic behaviour (for example, robustness
towards faults) and performance optimization (for example, load balancing).

BASIC REAL-TIME CONCEPTS
TERMINOLOGY
 The fundamental definitions of real-time systems engineering can vary depending on
the resource consulted.
 The following definitions have been collected and refined to the smallest common
subset of agreement to form the vocabulary of this text.
 Moreover, these definitions are presented in a form that is intended to be most useful
to the practicing engineer, as opposed to the theorist
Systems Concepts
 The hardware of the general-purpose computer solves problems by repeated
execution of macroinstructions, collectively known as software.
 Software is traditionally divided into system programs and application programs

 Application programs are programs written to solve speciﬁc problems, such as payroll
preparation, inventory, and navigation.
 Certain design considerations play a role in the design of certain systems programs and
application software intended to run in real-time environments.
 The notion of a “system” is central to software engineering, and indeed to all engineering,
and warrants formalization

TypicalReal-
timecontrolsystemincludinginputsfromsensorsandimagingdevices and
producing control signals and display information.

A classic representation of a real-time system as a sequence of jobs
to be scheduled.
 Deﬁnition: The time between the presentation of a set of inputs to a system
(stimulus) and the realization of the required behavior (response), including the
availability of all associated outputs, is called the response time of the system.

 Real-Time Definitions The previous definitions set the stage for a formal definition
of a real-time system.
 Definition: A real-time system is a system that must satisfy explicit (bounded)
response-time constraints or risk severe consequences, including failure
 Definition: A failed system is a system that cannot satisfy one or more of the
requirements stipulated in the formal system specification.
 Definition: A real-time system is one whose logical correctness is based on both the
correctness of the outputs and their timeliness.

REAL-TIME SYSTEM DESIGN ISSUES
 Real-time systems are a complex subdiscipline of computer systems engineering
that is strongly inﬂuenced by control theory, software engineering, and operations
research (via scheduling theory).
 Figure 1 depicts just some of the disciplines of computer science and electrical
engineering that affect the design and analysis of real-time systems.
 Thus, because real-time systems engineering is so multidisciplinary, it stands out as
a highly specialized area.
 The design and implementation of real-time systems requires attention to numerous
problems.
 These include:
 The selection of hardware and software, and evaluation of the trade-off needed
for a cost-effective solution, including dealing with distributed computing systems
and the issues of parallelism and synchronization

.
Disciplines that impact on real-time systems engineering

Embedded System and Embedded Controllers.pptx

COMMON MISCONCEPTIONS
As a part of truly understanding the nature of real-time systems, it is important to address
a number of frequently cited misconceptions. These are summarized as follows:
1. Real-time systems are synonymous with “fast” systems.
2. Rate-monotonic analysis has solved “the real-time problem.”
3. There are universal, widely accepted methodologies for real-time systems speciﬁcation
and design.
4. There is never a need to build a real-time operating system, because many commercial
products exist.
5. The study of real-time systems is mostly about scheduling theory.

Commercial Operating System Support
 The ﬁrst commercial operating systems were designed for mainframe computers.
IBM developed the ﬁrst real-time executive.
 its Basic Executive in 1962, which provided diverse real-time scheduling.
 By 1963, its Basic Executive II had disk resident user/systems programs.
 By the mid 1970s more affordable minicomputer systems could be found in many
engineering environments.
 In response, a number of important real-time operating systems were developed by
the minicomputer manufacturers.
 Notable among these were the Digital Equipment Corporation (DEC) family of real-
time multitasking executives (RSX) for the PDP-11 and Hewlett-Packard’s Real-Time

 By the late 1970s and early 1980s, the ﬁrst operating systems for
microprocessor-based systems appeared.
 These included RMX-80, MROS 68K, VRTX, and several others.
 Over the last 20 years many real-time operating systems have appeared
and many have disappeared.
 A summary of some of the landmark events in the ﬁeld of real-time
systems in the United States is given in Table

ARM7 REAL TIME APPLICATIONS
AT91 ARM® Thumb®-based Microcontrollers
AT91SAM7S256
Atmel’s AT91SAM7S256 is a member of a series of low pincount Flash microcontrollers
based on the 32-bit ARM RISC processor.
It features a 256 Kbyte high-speed Flash and a 64 Kbyte SRAM, a large set of
peripherals, including a USB 2.0 device.
A complete set of system functions minimizing the number of external components.
The device is an ideal migration path for 8-bit microcontroller users looking for
additional performance and extended memory.
The embedded Flash memory can be programmed in-system via the JTAG-ICE interface
or via a parallel interface on a production programmer prior to mounting.

Built-in lock bits and a security bit protect the firmware from accidental overwrite
and preserves its confidentiality.
The AT91SAM7S256 system controller includes a reset controller capable of
managing the power-on sequence of the microcontroller and the complete system.
 Correct device operation can be monitored by a built-in brownout detector and a
watchdog running off an integrated RC oscillator.
The AT91SAM7S256 is a general-purpose microcontroller. Its integrated USB Device
port makes it an ideal device for peripheral applications requiring connectivity to a
PC or cellular phone.
 Its aggressive price point and high level of integration pushes its scope of use far
into the cost-sensitive, high-volume consumer market.

FEATURES
• Incorporates the ARM7TDMI® ARM® Thumb® Processor
– High-performance 32-bit RISC Architecture
– High-density 16-bit Instruction Set
– Leader in MIPS/Watt
– Embedded ICE In-circuit Emulation, Debug Communication Channel Support
• 256 Kbytes of Internal High-speed Flash, Organized in 1024 Pages of 256 Bytes
– Single Cycle Access at Up to 30 MHz in Worst Case Conditions
– Prefetch Buffer Optimizing Thumb Instruction Execution at Maximum Speed
– Page Programming Time: 4 ms, Including Page Auto-erase, Full Erase Time: 10 ms
– 10,000 Write Cycles, 10-year Data Retention Capability, Sector Lock Capabilities,
Flash Security Bit
– Fast Flash Programming Interface for High Volume

Production
• 64 Kbytes of Internal High-speed SRAM, Single-cycle Access at Maximum Speed
• Memory Controller (MC)
– Embedded Flash Controller, Abort Status and Misalignment Detection
• Reset Controller (RSTC)
– Based on Power-on Reset and Low-power Factory-calibrated Brown-out Detector
– Provides External Reset Signal Shaping and Reset Source Status
• Clock Generator (CKGR)
– Low-power RC Oscillator, 3 to 20 MHz On-chip Oscillator and one PLL
• Power Management Controller (PMC)
– Software Power Optimization Capabilities, Including Slow Clock Mode (Down to
500 Hz) and Idle Mode
– Three Programmable External Clock Signals
• Advanced Interrupt Controller (AIC)
– Individually Maskable, Eight-level Priority, Vectored Interrupt Sources
– Two External Interrupt Sources and One Fast Interrupt Source, Spurious Interrupt
Protected
• Debug Unit (DBGU)

Programmable ICE Access Prevention
• Periodic Interval Timer (PIT)
– 20-bit Programmable Counter plus 12-bit Interval Counter
• Windowed Watchdog (WDT)
– 12-bit key-protected Programmable Counter
– Provides Reset or Interrupt Signals to the System
– Counter May Be Stopped While the Processor is in Debug State or in Idle Mode
• Real-time Timer (RTT)
– 32-bit Free-running Counter with Alarm
– Runs Off the Internal RC Oscillator
• One Parallel Input/Output Controller (PIOA)
– Thirty-two Programmable I/O Lines Multiplexed with up to Two Peripheral I/Os
– Input Change Interrupt Capability on Each I/O Line
– Individually Programmable Open-drain, Pull-up resistor and Synchronous Output
• Eleven Peripheral DMA Controller (PDC) Channels
• One USB 2.0 Full Speed (12 Mbits per second) Device Port
– On-chip Transceiver, 328-byte Configurable Integrated FIFOs

Processor and Architecture
ARM7TDMI Processor
• RISC processor based on ARMv4T Von Neumann architecture
– Runs at up to 55 MHz, providing 0.9 MIPS/MHz
• Two instruction sets
– ARM® high-performance 32-bit instruction set
– Thumb® high code density 16-bit instruction set
• Three-stage pipeline architecture
– Instruction Fetch (F)
– Instruction Decode (D)
– Execute (E)
Debug and Test Features
• Integrated embedded in-circuit emulator
– Two watchpoint units
– Test access port accessible through a JTAG protocol
– Debug communication channel
• Debug Unit
– Two-pin UART

– Debug communication channel interrupt handling
– Chip ID Register
• IEEE1149.1 JTAG Boundary-scan on all digital pins
Memory Controller
• Bus Arbiter
– Handles requests from the ARM7TDMI and the Peripheral DMA Controller
• Address decoder provides selection signals for
– Three internal 1 Mbyte memory areas
– One 256 Mbyte embedded peripheral area
• Abort Status Registers
– Source, Type and all parameters of the access leading to an abort are saved
– Facilitates debug by detection of bad pointers
• Misalignment Detector
– Alignment checking of all data accesses
– Abort generation in case of misalignment

• Remap Command
– Remaps the SRAM in place of the embedded non-volatile memory
– Allows handling of dynamic exception vectors
• Embedded Flash Controller
– Embedded Flash interface, up to three programmable wait states
– Prefetch buffer, bufferizing and anticipating the 16-bit requests, reducing the
required wait states
– Key-protected program, erase and lock/unlock sequencer
– Single command for erasing, programming and locking operations
– Interrupt generation in case of forbidden operation

Peripheral DMA Controller
• Handles data transfer between peripherals and memories
• Eleven channels
– Two for each USART
– Two for the Debug Unit
– Two for the Serial Synchronous Controller
– Two for the Serial Peripheral Interface
– One for the Analog-to-digital Converter
• Low bus arbitration overhead
– One Master Clock cycle needed for a transfer from memory to peripheral
– Two Master Clock cycles needed for a transfer from peripheral to memory
• Next Pointer management for reducing interrupt latency requirements

Memory
• 256 Kbytes of Flash Memory
– 1024 pages of 256 bytes
– Fast access time, 30 MHz single-cycle access in worst case conditions
– Page programming time: 4 ms, including page auto-erase
– Page programming without auto-erase: 2 ms
– Full chip erase time: 10 ms
– 10,000 write cycles, 10-year data retention capability
– 16 lock bits, each protecting 16 sectors of 64 pages
– Protection Mode to secure contents of the Flash
• 64 Kbytes of Fast SRAM
– Single-cycle access at full speed

Introduction to ARM7 Programming

ABITEC’s APPLICATIONS BOARD
 Is designed to provide the student with a vehicle to attain the skills required to
develop systems which respond to ‘real time’ events.
 This is achieved by providing a cross section of input /output devices on a single
compact board that can be interfaced to various controlling systems via a single 40
pin IDC connector.
System Facilities
The applications board has the following facilities:
• Eight large LED array.
• Eight-slider switch array.
• Two Dual seven segment displays.
• DC Motor & control.
The motor is equipped with a three-blade propeller which interrupts an IR LED and sensor,
the output of which is converted to a digital signal and is readable on one of the outputs
from the applications board.
• Semiconductor temperature sensor.

• Heater control circuit.
The heater is in contact with the temperature sensor and the motor propeller can be made
to pass air over them causing a cooling effect.
• A standard telephone type 3 x 4 matrix keypad.
• Fibre Optic transmitter and receiver.
• An 8-bit Digital to Analogue Converter (DAC) and comparator to enable the
programming of Analogue to Digital Converter (ADC) functions
 Slider potentiometer providing a variable analogue voltage.
• Speaker driven either form a digital signal or from the output of the DAC.
 The following options are also available:
• LCD interface circuit & LCD Display.
• Stepper motor control circuit.

SYSTEM OPERATION
 The Applications Board is controlled by two eight bit ports, port 1 and port 2, via the 40
pin IDC connector P2.
 The microprocessor/microcontroller system controlling the applications board must
configure its ports (sometimes dynamically) in order to perform various operations.
 Some of the board functions are enabled/disabled using the Control Switches SW1 -
SW9.
 SW1 to SW8 are grouped in the centre of the applications board whilst SW9 is situated
in the Fibre Optic Link area.
POWER REQUIREMENT
 Power (8V to 20V DC unregulated up to 1 Amp) is applied to connector P1, this is then
regulated to 5V DC by REG1 providing power for the whole board.

System Connection ABITEC products
 8086-DATS, 8051-DATS, 877-DATS, PLDATS, DIO-ADP1, Z80-DATS, ARM7S-TB
and ARM3S-TB, MC11-DATS (with CAB-MC11), & KAYCOMPII (68000).
 systems are pin compatible with the Applications Board but it can be controlled
from any microprocessor or microcontroller system equipped with two
programmable eight bit ports.
 The applications board is connected to the controlling system via a 40 way IDC
connector, pin function details can be seen in section 3.
 All connections to both the applications board and the controlling system should
be made BEFORE power is applied to either unit.
 An overview of the application boards facilities is shown in figure 1.1.

CIRCUIT FEATURES
 This section gives details of each functional part of the applications board in turn,
providing the user with all the information required to use that part of the board.
 In order to include numerous I/O devices on the applications board sharing two eight bit
ports a number circuits must ‘share’ bits.
 Bit functions have been allocated to allow the most flexible operation of both the
individual circuits and combination of circuits.
 The various bit functions are shown in table 2.1.

SWITCH ARRAY
 General input in provided by an array of eight slide switches connected to Port 1.
 When in an open position, a logic 1 is read, when closed a logic 0 is read. The switch
arrangement and circuit diagram are shown in figures 2.1 and 2.2 respectively.
 Note: Since port 1 is ‘shared’ with other application circuits, the switches should be left in
the OFF (UP) position when not used. This leaves each bit of port 1 free for other
functions.

LED Array
 Port 2 provides a general output facility driving an array of eight large ‘tombstone’
LED’s.
 These are colour coded to allow simulation of traffic lights and a pedestrian crossing.
 Each LED is driven via an inverter.
 Outputting a logic 1 lights the LED whilst outputting a logic 0 turns the LED off.
 Note that when driving other circuits on port 2 the LED’s remain connected and therefore
will still turn on and off.
 The LED array layout and circuit diagram is shown if figures 2.3 and 2.4 respectively

SEVEN SEGMENT DISPLAY
 The Applications Board provides four seven segment displays.
 The segments are driven form port 1 whilst each digit is enabled by bits D0 to D3 of port
2.
 The segments are illuminated by applying a logic 1 and each digit is enabled by
outputting a logic 1.
 The segments of all four displays are connected, hence to display data the user must
multiplex the display in software.
 The whole display is enabled or disabled with control switch SW8, down for on and up for
off.
 The layout and circuit diagram are shown in figures 2.5 and 2.6 receptively

SEVEN SEGMENT DISPLAY
// Initial CPP Source File
#include “xstdsys.h”
main()
{
unsigned int data_in, output;
static const unsigned int PATTERN[10]={0x3f00, 0x3000, 0x5b00, 0x4f00, 0x6600, 0x6d00, 0x7d00,
0x0700, 0x7f00, 0x6700}; //patterns for seven segment
const unsigned int SWTS=0xff;
const unsigned int LEDS=0xff00; //switches
const unsigned int DIGITS=0x0f; //digit enable bits
g_pPMC->PCER = PID2;
g_pPIOA->PER = 0xffff; //enable PIO
g_pPIOA->OER = LEDS | DIGITS; //enable output to LEDS
g_pPIOA->OWER = LEDS | DIGITS; //mask for synchronous write out to LEDS

while(1)
{
data_in=(g_pPIOA->PDSR & SWTS)>>4; //read switches and shift right
data_in=(data_in & 0x0f); //mask 4 bits required
if(data_in>9) data_in=9; //max digit 9
output=(PATTERN[data_in]); //get pattern
g_pPIOA->ODSR = output; //write to LEDS
g_pPIOA->SODR = 1; //enable digit
}
}

CONTROLLING THE DC MOTOR
void delay(unsigned int count);
void delay(unsigned int count)
{
unsigned int i, j;
for(i=0; i<count; i++)
for(j=0; j<300; j++)
}
main()
{
const unsigned int MOTOR_ON=0x20;
const unsigned int MOTOR_OFF=0;
g_pPIOA->OER = 0x60; //enable outputs to motor control bits
g_pPIOA->OWER = 0x60; //mask for synchronous motor control bits
while(1)
{
g_pPIOA->ODSR = MOTOR_ON;
delay(500);
g_pPIOA->ODSR = MOTOR_OFF;
delay(1000);
}
}

{
unsigned inti, j;
for(j=0; j<300; j++)
}
main()
{
const unsigned int MOTOR_ON=0x20;
const unsigned int MOTOR_OFF=0;
const unsigned int IRSENSOR_BIT=0x10;
g_pPIOA->OER = 0x60; //enable outputs to motor control bits
g_pPIOA->OWER = 0x60; //mask for synchronous motor control bits

while(1)
{
do
{
g_pPIOA->ODSR = MOTOR_ON; //motor ON
}
while (g_pPIOA->PDSR & IRSENSOR_BIT);// until sensor=0
g_pPIOA->ODSR = MOTOR_OFF; //motor OFF
delay(100); //speed control
do
{
g_pPIOA->ODSR = MOTOR_ON; //motor ON
}
while (!g_pPIOA->PDSR & IRSENSOR_BIT);// until sensor=1
g_pPIOA->ODSR = MOTOR_OFF; //motor OFF
}
}

FIBRE OPTIC RECEIVER & TRANSMITTER
 The Fibre optic section of the Applications Board consists of a transmitter and receiver
which may be linked together or with another system.
 The transmitter is switched on by applying a logic one to port 2 bit 0, the receiver is read
by examining port 1 bit 6. The circuit diagram is shown in figure

{
unsigned inti, j;
for(j=0; j<300; j++)
}
void set_led(unsigned int value)
{
if(value == 1)
{g_pPIOA->SODR = 0x8000;} output logic 1 on LED
else
{g_pPIOA->CODR = 0x8000;} output logic 0 on LED
}

main()
{
const unsigned int RECEIVER=0x40;
const unsigned int TRANSMITTER=0x8100;
g_pPIOA->OER = TRANSMITTER; //enable outputs to LEDS
g_pPIOA->OWER = TRANSMITTER; //mask for sync. write to LEDS
while(1)
{
g_pPIOA->SODR = 0x100; //output logic 1 on transmitter
delay(1000); //wait
if(g_pPIOA->PDSR & RECEIVER)
{set_led(1);}
else set_led(0);
g_pPIOA->CODR = 0x100; //output logic 0 on transmitter
delay(1000); //wait
if(g_pPIOA->PDSR & RECEIVER)
{set_led(1);}
else set_led(0);
}
}

STEPPER MOTOR INTERFACE (OPTIONAL)
 The Stepper Motor Interface is designed round the motor drive and interface i.c.
M5804. Four bits, D4 - D7 on port 1 control the stepper motor as shown in table
2.3.
 The condition of the drive circuit is indicated by four LED’s D8 - D11. The stepper
motor is connected to the applications board via connector P3.

THE FUNCTION OF EACH BIT IS AS FOLLOWS:
• One-Phase (D7) When this bit is set to a logical one the I.C. is set to One Phase stepping
mode.
• Half-Step (D6) When a logical one is applied to this bit, the I.C. is set to Half Step mode.
Note that if bits 6 & 7 are both set to a logical zero, the I.C. is set to Full Step mode.
When bits 6 & 7 are both set to a logical one, the I.C. is set to Inhibit mode and incoming
step pulses are ignored.
Table 2.4 summarises these operations.
• Step (D5) When this bit changes from a logical one to a logical zero the motor executes
one step dependant on the step mode selected.
• Direction (D4) This bit sets the direction of rotation of the motor. The actual direction will
depend on the winding orientation of the stepper motor connected to the applications board

{
unsigned inti, j;
for(j=0; j<30000; j++);
}
main()
{
int j;
const unsigned int STEPPER=0xf0;
g_pPIOA->OER = STEPPER; //enable output to STEPPER
g_pPIOA->OWER = STEPPER; //mask for sync. write to STEPPER
g_pPIOA->ODSR = 0x90; //set up stepper bits
while(1)
{
g_pPIOA->CODR = 0x20; //clear step bit
delay(25);
g_pPIOA->SODR = 0x20; //set step bit
}

Embedded System and Embedded Controllers.pptx

More Related Content

Similar to Embedded System and Embedded Controllers.pptx (20)

More from Divya Somashekar (16)

Recently uploaded (20)

Embedded System and Embedded Controllers.pptx