Final Report

1 | P a g e

ACKNOWLEDGEMENTS

I take immense pleasure in thanking Prof. M.Bhaskar Rao, Director of Practice School for

implementing Practice School Program at K L University effectively.

I wish to express our deep sense of gratitude to our Company Guide, Mr. K.Pavan Kumar,

Design Engineer (Embedded Systems), Vyas Informatics and Mr.V.Mahendra, Technical

Guide for their able guidance and useful suggestions, which helped me in completing the

project work in time. I would also like to thank Mr.Abid Ali, Design Engineer (Embedded

Systems) and Mr. J.Pradeep, Application Engineer (Embedded Systems) for their guidance

in completion of the project.

Needless to mention that Mr.C.Sriram, Regional Manager of Practice School, Hyderabad

and Operational guide who had been a source of inspiration and for his timely guidance in the

conduct of our project work. I would also like to thank Mr.Nagendra, Assistant

Manager(Operations) for his valuable assistance in the project work.

Finally, yet importantly, I would like to express my heartfelt thanks to my beloved parents for

their blessings, classmates for their help and wishes for the successful completion of this

project.

2 | P a g e

List of paradigms

1. Single functioned Embedded System.

2. Reactive and real time system (a).

3. Reactive and real time system (b).

4. MPEG streaming application.

List of figures

Fig. 1.1.2.a Representative architecture layers of an Embedded System.

Fig. 1.1.2.b Major application areas of Embedded System.

Fig. 1.2.a Global embedded system revenue – Comparison ‘04 to ‘09.

Fig. 1.2.b World embedded system revenue – Comparison ‘04 to ‘09.

Fig. 5. Block diagram of the project.

Fig. 6.1 Block diagram of the RT Kernel.

Fig. 8. Model object of LPC1768 from Coinel Technologies.

Fig. 8.3 Block diagram of Cortex M3.

Fig. 9. Block diagram of Clocking and Power control.

Fig. 10.a Model object of Graphical LCD TM12864HCCOWA.

Fig. 10.b Internal block diagram of TM12864HCCOWA.

Fig. 10.2.a Paging scheme of TM12864HCCOWA.

Fig. 10.2.b Pin configuration of TM12864HCCOWA.

Fig. 10.2.c Block diagram of TM12864HCCOWA.

Fig. 11.2.a UART core architecture.

Fig. 11.2.b Pin description of UART.

Fig. 11.2.c Port description of UART modem.

Fig. 11.3 Standard serial data format of UART.

Fig. 11.3.a Create project window in Keil uVision.

Fig. 12.2.a.a Device selection window.

Fig. 12.2.a.b Startup code window.

Fig. 12.2.a.c Configuring components, environments, books.

Fig. 12.2.a.d Configuring components, environments, books.

Fig. 12.2.b Configuring Target1.

Fig. 12.2.c.a Configuring output.

Fig. 12.2.c.b Configuring linker,asm options for target.

Fig. 12.2.d.a Configuring debugging options.

Fig. 12.2.d.b Change options for utilities.

Fig. 12.2.e.a Compilation and generation of Hex file.

Fig. 12.2.e.b Implementation of Hex file using Flash Magic.

3 | P a g e

Overview of the Industry

1.1 Introduction :

An ‗Embedded system‘ is a combination of computer hardware, software, and additional

mechanical or other technical components, designed to perform a dedicated function. Most of

the embedded systems need to meet real-time computing requirements. They have become an

integral part of daily life. Be it a cell phone, a smartcard, a music player, a router, or the

electronics in an automobile - these systems have been touching and changing modern lives

like never before.

They are found in a variety of common electronic devices, such as:

(a) Consumer Electronics - Cell phones, Pagers, Digital cameras, Camcorders,

Videocassette recorders, Portable video games, Calculators, and Personal Digital Assistants;

(b) Home Appliances - Microwave Ovens, Answering Machines, Thermostat, Home

security, Washing machines, and Lighting systems;

(c) Office Automation - Fax machines, Copiers, Printers, and Scanners;

(d) Business Equipment - Cash registers, Curbside check-in, Alarm systems, Card readers,

Product Scanners, and Automated Teller Machines;

(e) Automobiles - Transmission control, Cruise control, Fuel injection, Anti-lock brakes, and

Active suspension.

One might say that nearly any device that runs on electricity either already has, or will soon

have, a computing system embedded within it.

4 | P a g e

1.1.1 Characteristics of an Embedded System

Embedded systems have several common characteristics:

1) Single-functioned: An embedded system usually executes only one program, repeatedly.

Paradigm 1 : A pager is always a pager. In contrast, a desktop system executes a variety of

programs, like spreadsheets, word processors, and video games, with new programs added

frequently.

2) Tightly constrained: All computing systems have constraints on design metrics, but those

on embedded systems can be especially tight.

A design metric is a measure of an implementation‘s features, such as cost, size,

performance, and power.

Embedded systems often must cost just a few money, must be sized to fit on a single chip,

must perform fast enough to process data in real-time, and must consume minimum power to

extend battery life or prevent the necessity of a cooling fan.

3) Reactive and real-time: Many embedded systems must continually react to changes in the

system‘s environment, and must compute certain results in real time without delay.

Paradigm 2 : A car's cruise controller continually monitors and reacts to speed and brake

sensors. It must compute acceleration or decelerations amounts repeatedly within a limited

time; a delayed computation result could result in a failure to maintain control of the car.

In contrast, a desktop system typically focuses on computations, with relatively infrequent

(from the computer‘s perspective) reactions to input devices. In addition, a delay in those

computations, while perhaps inconvenient to the computer user, typically does not result in a

system failure.

Paradigm 3 : Consider a digital camera system. The A to D and D to A circuits convert

analog images to digital and digital to analog, respectively. The CCD preprocessor is a

5 | P a g e

charge-coupled device preprocessor. The JPEG codec compresses and decompresses an

image using the JPEG2 compression standard, enabling compact storage in the limited

memory of the camera.

The Pixel coprocessor aids in rapidly displaying images. The Memory controller controls

access to a memory chip also found in the camera, while the DMA controller enables direct

memory access without requiring the use of the microcontroller.

The UART enables communication with a PC‘s serial port for uploading video frames, while

the ISA bus interface enables a faster connection with a PC‘s ISA bus. The LCD ctrl and

Display ctrl circuits control the display of images on the camera‘s liquid-crystal display

device. A Multiplier/Accum. circuit assists with certain digital signal processing. At the heart

of the system is a microcontroller, which is a processor that controls the activities of all the

other circuits.

We can think of each device as a processor designed for a particular task, while the

microcontroller is a more general processor designed for general tasks. This example

illustrates some of the embedded system characteristics described above.

First, it performs a single function repeatedly. The system always acts as a digital camera,

wherein it captures, compresses and stores frames, decompresses and displays frames, and

uploads frames. Second, it is tightly constrained. The system must be low cost since

consumers must be able to afford such a camera. It must be small so that it fits within a

standard-sized camera. It must be fast so that it can process numerous images in milliseconds.

It must consume little power so that the camera‘s battery will last a longtime.

However, this particular system does not posses a high degree of the characteristic of being

reactive and real-time, as it only needs to respond to the pressing of buttons by a user, which

even for an avid photographer is still quite slow with respect to processor speeds.

1.1.2 Building blocks of an Embedded System

The major building blocks of an embedded system are listed below:

• Microcontrollers / digital signal processors (DSP)

6 | P a g e

• Integrated chips

• Real time operating system (RTOS) - including board support package and device drivers

• Industry-specific protocols and interfaces

• Printed circuit board assembly

Usually, an embedded system requires mechanical assembly to accommodate all the above

components and create a product or a complete embedded device. The following figure

illustrates the architecture layers for an embedded system.

Figure 1.1.2.a - Representative architecture layers of an Embedded System

The lowermost layer comprises the printed circuit board that accommodates all the

semiconductor devices, buses and related electronics. The semiconductor devices may

include integrated chips, microcontrollers, field-programmable gate arrays (FPGAs) or a

system-on-chip (SoC).

The uppermost layer is the application layer. In-between, there are other layers which may

comprise components like device drivers and communication protocols. A special genre of

operating systems known as the real-time operating system (RTOS) is usually required to

cater to the deadline-driven requirements of an embedded system.

7 | P a g e

There are some key differences in the design and use of embedded systems as compared to

the general computing devices. They perform a limited set of pre-defined functions and have

a limited field configuration capability. The packaging into which they are embedded is also

standardized. These features enable embedded systems to be relatively static and simple in

functionality. However, there is a requirement for low cost, small physical footprint and

negligible electrical / electronic radiation and energy consumption. Simultaneously, they need

to be physically rugged and impervious to external electrical and electronic interference.

Therefore, embedded systems invariably have limited resources available in terms of

memory, CPU, screen size, a limited set (or absence) of key inputs, diskless operations -

these parameters play a crucial part during the design, development and testing of such

systems. They also require a host of diverse skill-sets related to hardware, embedded

software, electronics and mechanical domains, which renders further complexity to their

development.

With increasing functionality, the selection of a particular technology, standard and

functionality for the next product release is at times a tough call for product managers and

architects. While a focus on innovation, upcoming standards and enriched user experience is

required, it is a challenge to decide which technology and idea to pursue and nurture.

1.1.3 Application areas of Embedded System

Figure 1.1.2.b - Major application areas of Embedded Systems

8 | P a g e

1.2 Global market of Embedded Systems over the decade :

This is a quick reference to analyse the market trend of Embedded Systems. As on with

consumer statistics it is depicted as an rapid change in global outcome :

Figure 1.2.a – Global Embedded Systems Revenue – Comparison ‘04 to ‘09

Figure 1.2.b – World Embedded Systems Revenue – Comparison ‘04 to ‘09

Dating back to past times while about 40% of American households had a desktop computer

in 1994, each household had an average of more than 30 embedded computers, with that

number expected to rise into the hundreds by the year 2000. The electronics in an average car

cost $1237 in 1995, and may cost $2125 by 2000.

Several billion embedded microprocessor units were sold annually in recent years, compared

to a few hundred million desktop microprocessor units.

According to a new market research report, ― Embedded Systems: Technologies and Markets

available at Electronics.ca Publications ‖, the global market for embedded systems

technologies was worth $92.0 billion in 2008. This will increase to $112.5 billion in 2013, for

a compound annual growth rate (CAGR) of 4.1%.

9 | P a g e

The market is broken down into segments for embedded hardware and embedded software.

Embedded hardware had the largest share of the market, worth $89.8 billion in 2008. This

should increase at a CAGR of 4.1% to reach $109.6 billion in 2013.

The embedded software segment has the second largest share of the market, worth $2.2

billion in 2008. This segment is expected to generate $2.9 billion in 2013, for a CAGR of

5.6%.

The ease of developing and marketing embedded devices is increasing with the advance of

technology and communication. Embedded devices are now starting to dominate nearly every

aspect of human life. Many new devices are being introduced into the global market every

day with innovative end applications. From cell phones to digital televisions to MP3 players

to refrigerators to washing machines, we are constantly using embedded devices for different

purposes, often unaware of the underlying technology.

Embedded hardware and software are what make these embedded devices work. The success

of the embedded devices is defined by how well designed and developed the device is, and if

it is using right underlying hardware that meets cost constraints.

The rise of the open source software movement on the web, coupled with low cost

engineering talent available via outsourcing, will ease the design and development of

embedded devices. The embedded hardware market will continue to flourish over the long

term as new applications emerge. The market for embedded computer systems, which already

generates more than US$1 trillion in revenue annually, will double in size over the next four

years, according to a report about to be released by research company IDC. Much of this

growth will be propelled by more sophisticated, cloud-connected embedded systems, which

will have faster chips, better connectivity and more advanced operating systems and

analytical software, IDC predicted.

IDC referred to these systems as ―Intelligent Systems,‖ and they will grow from 19% of all

unit shipments of major electronic systems in 2010 to more than 33% in 2015.

1 0 | P a g e

IDC’s report, “Intelligent Systems: The Next Big Opportunity” states that this year more

than 1.8 billion embedded systems will be shipped, which will create $1 trillion in revenue

for component makers, software companies and integrators.

By 2015, more than 4 billion units will be shipped, which will create $2 trillion in revenue.

Moreover, embedded systems will require 14.5 billion microprocessor cores by 2015.

Embedded systems are small computational and sensor-based electronic components that

collect data and automate simple actions. They are widely used in both consumer and

industrial applications, such as vending machines, refrigerators, digital music players,

automobiles and routine assembly line tasks. As the cost and power requirements of

microprocessors continue to plummet, the use of sophisticated microcontrollers becomes

more feasible for a wider variety of tasks.

―We’re seeing more and more of our customers who look at these devices as a huge

source of data that they can use to drive increased business efficiencies in business

intelligence,‖ - Kevin Dallas, General Manager of the Windows Embedded Business at

Microsoft.

―Microsoft itself is enhancing its Windows Embedded operating system to accommodate the

future needs of more complex embedded systems,‖ Dallas said. ―For instance, it is

developing a machine-to-machine connection manager, code-named Pontecchio, that would

offer fine-grained control over when devices connect to network services, which would make

their data transfers more predictable‖

For the report, the IDC researchers looked at buying habits across seven major industries,

namely communications, computing, consumer, energy, health care, industrial and

transportation. They also examined the road maps of the major processor architectures,

including ARM, MIPS, IBM‘s Power Architecture and x86.

Over 4 billion embedded processors were sold in 2009 and the global market is worth €60

billion with annual growth rates of 14%. Forecasts predict more than 16 billion embedded

devices by 2010 and over 40 billion by 2020.

Embedded computing and electronics add substantial value to products. Within the next five

years, the share of embedded systems are expected to increase substantially in markets such

1 1 | P a g e

as automotive (36%), industrial automation (22%), telecommunications (37%), consumer

electronics (41%) and health/medical equipment (33%). The value added to the final product

by embedded software is much higher than the cost of the embedded device itself.

For example, in the case of a modern car, by 2010 over 35% of its value will be due to

embedded electronics.

This accounts for 90% of new innovations and features in:

Engine Management (improved efficiency and reduced emissions)

Safety features (like stability control, antilock braking and airbags)

Comfort (navigation and entertainment features)

Similarly, a modern cellular phone has more features than those of a laptop from a few years

ago with integrated digital camera, camcorder, video/music player and, of course, a phone!

1.3 Trend analysis - Embedded market of India :

1.3.1 what’s the market like?

Spurred by increasing sales of electronics and burgeoning telecom sector, the Indian

semiconductor design industry is all set to reach $10.2 billion by 2012, from $7.5 billion in

2010, says a report by the ― India Semiconductor Association (ISA) ―.

The Indian chip design industry, which comprises very-large-scale integration (VLSI) design,

embedded software development and board design, is expected to grow 17.3 per cent year-

on-year to reach the whopping figure of $10.2 billion by 2012. This tremendous rate of

growth will also require a large number of skilled professionals to increase the quality of

work churned out.

The report further adds that the Indian semiconductor design industry employed a workforce

of 160,000 in 2010, of which embedded software accounts for as much as 82 per cent

employment. Thus highlighting the fact that embedded systems open up a plethora of

opportunities for their practitioners.

1 2 | P a g e

India‘s semiconductor consumption is projected to reach $8.2 billion in 2011, a 15.5 per cent

jump from 2010 consumption of $7.1 billion, according to research firm Gartner Inc. Based

on this forecast, India is the fastest growing market in terms of semiconductor consumption

for 2011.

― Changing demographics, increasing consumer affluence, economic growth and

favorable government policy continues to drive the electronic equipment manufacturing

industry in India. Numerous global electronic equipment manufacturing companies have set

up production facilities in India to take advantage of the growing domestic market, and to

cater to neighbouring markets in the region. As a result, semiconductor consumption is also

growing at a rapid pace,‖- Ganesh Ramamoorthy, Research Director, Gartner.

― Given the low penetration and the growing demand for key electronic equipment

such as mobile phones, desktops, laptop computers and LCD TVs, we believe the Indian

market will be able to easily sustain high growth rates in the coming years. Therefore we

expect India’s semiconductor consumption to grow the fastest across the globe through 2015

at a compound annual growth rate of 15.9 per cent to reach nearly $15 billion. Through

2015, nearly three-fourth of India’s semiconductor consumption will be accounted for by

these three electronic equipment segments,‖ Ramamoorthy added.

― Nearly 2000 chips are being designed in India every year, with more than 20,000

engineers getting engaged in various aspects of chip design and verification. ―With India

becoming the hub for semiconductor design, the embedded industry offers tremendous job

opportunities countrywide. If you plan to enter into this field, you need not worry about the

respective job prospects. We require tons of embedded professionals to create all that is

possible—be it in telecom, networking, automotive, medical and so on,‖- quips Venkatesh

Kumaran, country manager, Wind River India.

1 3 | P a g e

1.3.2 Roles Available :

Embedded engineers write the software that controls the VLSI chips. Embedded software can

be any code which interacts with the hardware layer, ranging from the hardware abstraction

layer, device drivers, kernel programming to application programming.

To take up embedded software development as career, you need to have a working

knowledge of C, C++ and Java, with some exposure to application software development. If

you have already done some programming for an embedded system, you can expand your

horizons by broadening your skill sets.

Embedded software is being developed using a variety of embedded and real-time operating

systems, such as embedded NT, Windows CE and RT Linux. In addition, a variety of

development tools and IDEs for C, C++ and Java are available. You need to learn application

development in these various environments.

To be a successful programmer, you need a good understanding of design alternatives : How

to choose a processor, an operating system, a programming language so that you can

develop cost-effective, reliable embedded software with minimal development time. As many

of the systems become network enabled, a working knowledge of network programming is

also important. Also, you need to be aware of the diversity of application areas and the

specific requirements of each.

As a hardware/board designer, you could work on reference board design, new board design,

and board design derivatives and modifications on existing boards. Reference boards are used

to validate the capabilities of designed silicon chips.

The embedded hardware designer is responsible for hardware design schematic, PCB layout,

BOM creation, hardware board debugging and testing, and system integration testing.

Desired skills are hardware design using 8-/16-/32-bit microcontrollers, microprocessor-

based systems, design of medium-frequency boards, hardware design of analogue, mixed

signal and digital, and understanding/ implementation of the EMI and EMC concepts to

hardware design.

1 4 | P a g e

“ 3.5 million jobs by 2015, but talent missing.. “

The Indian semiconductor design industry, comprising very large-scale integrated (VLSI)

design, board design and embedded software companies, has set its footprints across the

country.

According to an ISA - Ernst & Young report of 2011, this industry was about $6.5 billion

in 2009 and is expected to log a compound annual growth rate of 17.3 per cent to reach $10.6

billion in 2012.

The report also suggests that the industry promises 3.5 million jobs by 2015. But

unfortunately, the industry is grappling with the problem of talent shortage.

Embedded software segment now offers more high-value activities relating to middleware,

driver design and associated applications. The main reason for increased adoption of

embedded software is its use by electronics companies for increased device functionality,

reduced time-to-market and reduction in costs.

1 5 | P a g e

2. Overview of the Company – Vyas Informatics

2.1 VISION AND MISSION:

Vyas Informatics - determined to deliver customer satisfaction, professionalism, superior

quality and innovation in rendering Engineering training and support services. They aim to

exceed the expectations of valued clients in providing effective engineering solutions.

Their mission is to serve more and more valued customers by rendering customized

Engineering training solutions and programs. They provide comprehensive Engineering

training and consulting services to cater the diverse needs of customers. They emphasize on

quality in all of their service delivery approaches.

To accomplish their mission, they adopt the mission objectives:

Delivering customized and comprehensive range of Engineering training services and

support solutions

Providing diversified delivery models in offering Engineering training

Providing services and support by adhering to high quality standards

Rendering training services with world-class infrastructure

Providing quality training service that are faster time-to-market

They serve customers with accountability by providing precision service, promoting

customer care and complying with the quality standards. Their workforce combines technical

training excellence with a superior understanding of student needs.

2.2 PRODUCTS :

The products produced by the Vyas Informatics are Trainer Boards like 8051 TRAINER

BOARD, 8051 PROGRAMMER, ATMEGA 16, ATMEGA 32, PIC16F877A, PIC18F4520

and different types of ARM processors and projects using PIC and ARDUINO boards.

1 6 | P a g e

2.3 VALUE SYSTEM:

Vyas Informatics keeps the value system at the highest pedestal. The values channelize each

of their decisions and deliveries. Giving utmost importance to the value system is

everybody's responsibility at Vyas Informatics. They use the value system as the driving

force to achieve business excellence. Their value system includes:

Demonstrating commitment and attentiveness in all their actions.

Delivering service with utmost care and thus exceeding the customer expectation.

Responding to the training requirements to offer better and quicker services

1 7 | P a g e

3. Executive summary

This project is designed to interface Graphical LCD, UART communication to ARM based

microcontroller. Data entry is through ISP programming and the received data is displayed on

Graphical LCD, 128X64 dot matrix monochrome LCD with MOSFET control on backlight

power.

The LPC1768 are based on a 16/32 bit ARM7 TDMI-S CPU with real time emulation and

embedded trade support, together with 128/512 kilobytes of embedded high speed flash

memory.

A 128-bit wide memory interface and a unique accelerator architecture enable 32-bit code

execution at maximum clock rate. For critical code size applications, the alternative 16-bit

thumb mode reduces code by more than 30% with minimal performance penalty. With their

compact 64 pin package, low power consumption, various 32-bit timers , 4-channel 10-bit

ADC, USB PORT, PWM channels and 46 GPIO lines with up to 9 external interrupt pins

these microcontrollers are particularly suitable for industrial control, medical systems, access

control and point-of-sale.

With a wide range of serial communications, interfaces, they are also very well suited for

communication gateways , protocol converters and embedded soft modems as well as many

other general purpose applications.

This project uses two power supplies, one is regulated 5v for modules and other is 3.3v for

microcontroller, 7805 three terminal voltage regulator is used for voltage regulation. Bridge

type full wave rectifier is used to rectify the ac output of secondary of 230/12V step down

transformer.

1 8 | P a g e

4. INTRODUCTION

The project ―GRAPHICAL LCD DEVICE DRIVER DEVELOPMENT FOR RT-KERNEL

BASED SYSTEM USING CORTEX M3 CORE‖ works about the designing process of a RT

Kernel that which facilitates any embedded application using Cortex M-3.

A system which is required to deliver it‘s service in a timely fashion is called a Real Time

System. Correctness of such systems not only depends on the result produced but also on the

time at which results are produced. In such systems the meeting of timing constraints thus

becomes a major design issue.

General purpose operating systems, like linux are not suitable for handling such real time

systems because their inability to guarantee execution and response time of tasks. They also

have some undesirable features, like large and unbounded interrupt latency, huge context

switch and system call overheads and lack of support for specifying timing constraints etc.,

which make them unsuitable for real time applications. Thus there is need for a real time

kernel.

5. BLOCK DIAGRAM

Figure 5- Block Diagram of the project

1 9 | P a g e

6. RT Kernel

RT Kernel is a compact and very fast real-time kernel for the embedded 32/16 bits

microprocessors. RT Kernel performs a preemptive priority-based scheduling and a round-

robin scheduling for the tasks with identical priority.

The current version of RT Kernel includes semaphores, mutexes, data queues, event flags and

fixed-sized memory pools. The system functions calls in the interrupts are supported. RT

Kernel is a fully portable, but the current RT Kernel has been ported for the ARM

microprocessors only.

6.1 OBJECTIVES:

This project is associated to a larger embedded systems project aiming to automatize the

design process of embedded application involving Cortex M-3. The objective was to develop

and implement an OS kernel with the following features :

a) Portability: In embedded system application, there are various varieties of computing

platforms available. Hence any kernel for the embedded systems should be easily

portable to various architectures.

b) Real time character: Our project has an inherent timing constraints associated with

them. Thus any kernel catering to the need of our system must have support for

specifying real time constraints.

c) Driver Framework: The usage of a kernel depends on the availability of device

drivers. An OS supporting large number of devices has the obvious advantage of

allowing the users to experiment with a variety of environments and devices.

d) Support for Multiprocessing: Since embedded systems may be based on

heterogeneous multiprocessing (say a general purpose chip and an application specific

FPGA processing unit), we need to take this into account while coding/designing the

kernel.

2 0 | P a g e

Figure 6.1-Block Diagram of RT Kernel

6.2 FEATURES OF RT KERNEL:

a) MODULARITY:

The designed RT Kernel is extremely modular. There are a clear set of functions defined for

doing jobs like thread, semaphore, scheduling, management and context switching, it has a

directory based separation of CPU/architecture dependent code from the architecture

independent code. This modular structure also makes RT kernel easily portable.

b) PLUGGABLE SCHEDULER:

We have defined a new concept of a scheduling API. RT Kernel schedules threads using a

scheduler object which has functions. Application developer can either choose, predefined set

of schedulers or define the scheduler object himself and thus optimize algorithms and data

structures used for scheduling.

c) TWO STAGE INTERRUPT HANDLER:

Since RT kernel caters to the demand of a real time computing environment which should

respond immediately to interrupts. This leads to a 2 level handling of interrupts- the fast

2 1 | P a g e

immediate interrupt handling function and the second half interrupt handling function which

runs with a thread context.

d) DEVICE SUPPORT:

RT kernel has a borrowed OS kit‘s device driver framework which enables it to support a

large variety of devices.

6.3 CONCEPTS for RT Kernel :

a) SCHEDULER API:

TASKS AND PROCESSES:

Any computer system be it Real Time or not, usually consists of a number of tasks or

processes. Each task is designed to carry out some logically independent component of the

application. Splitting an application in this way overall manner improves throughput of the

system by achieving parallelism between the various components of the system.

Paradigm 4 : Consider a typical MPEG streaming application. An application like that might

be split into three threads, one for carrying out the input output, another for MPEG decoding

and last for displaying. Splitting the application in this manner else in achieving parallelism

between the network hardware, the CPU and the video controller.

One very important distinction between a real time system and a typical non real system is

using the nature of tasks and processes in them. A task in a real time system is much

deterministic. Prior knowledge is often available about one or more of the following tasks

attributes.

The number of tasks

Nature- periodic, aperiodic, periodicity

Deadlines

Execution times

Resource requirements

2 2 | P a g e

In this regard typical non real time systems like a PC system are much more non

deterministic. The number and nature of tasks in those system are very much dependent on

environment like the number of users currently logged in etc.

Because of these differences between a real time system and normal PC system, a scheduling

algorithm used in them is expectedly quite different: Operating system for the later type of

systems are written keeping this in mind. The scheduling algorithms used in such a system

are designed to reduce the average response time of processes.

On the other hand operating systems for real time systems use entirely different scheduling

algorithms. Here the aim is usually not reducing the average response times of processes, but

to have better throughput and to guarantee job deadlines.

There is also a wide difference between different real time systems in regard to their

scheduling requirements. For example ROUND ROBIN SCHEDULING is suitable for a real

time network switch, its not at all suitable for residence constraint jobs. Hence a real time OS

should have the future where the application developer can choose which scheduling

algorithm to use for that particular application.

We have proposed and developed a framework where the scheduler is not a part of the kernel

but a part of the application. This allows the application developer to write his own

customized scheduler, most suitable for the particular application, and hence optimize on

scheduling overheads.

The kernel interacts with the scheduler through a set of functions. Broadly it works as

follows: whenever a thread is created the kernel calls a scheduler function passing as

argument the newly created thread. The scheduler is expected incorporate the new thread into

its own data structure. Subsequent scheduling algorithm of the thread and of all other threads

in the system is for scheduler to decide. Each context switch times kernel calls a scheduler

function to find out which thread to schedule next.

2 3 | P a g e

b) SCHEDULING RULES

In RT Kernel, as long as the highest privilege task is running, no other task will execute

unless the highest privilege task cannot execute (for instance, for being placed in the

WAITING state). Among tasks with different priorities, the task with the highest priority is

the highest privilege task and will execute. Among tasks of the same priority, the task that

entered into the runnable (RUNNING or READY) state first is the highest privilege task and

will execute.

Example: Task A has priority 1, tasks B, C, D, E have priority 3, tasks F,G have priority 4,

task I has priority 5.

If all tasks are in the READY state, this is the sequence of tasks executing :

1. Task A - highest priority (priority 1)

2. Tasks B, C, D, E - in order of entering into runnable state for this priority (priority 3)

3. Tasks F, G - in order of entering into runnable state for this priority (priority 4)

4. Task I - lowest priority (priority 5)

In RT Kernel, tasks with the same priority may be scheduled in round robin fashion by

getting a predetermined time slice for each task with this priority.

c) INTERRUPT HANDLING:

An interrupt is a signal that the hardware can send when it wants the processor attention.

Interrupts are asynchronous to the threads running on the CPU. It becomes the responsibility

of the kernel to service these interrupts as immediately as it can at a ―safe‘ time.

Interrupt handling is one feature that makes a real time OS considerably different from a

general purpose OS. A real time OS needs to respond to real time events and should have

minimum possible interrupt latency. Secondly, since some critical real time systems need to

respond to the external device in bounded time, therefore there should be a bounded

maximum interrupt latency.

The delay in execution of the interrupt service routine from the time the device raises the

interrupt is called interrupt latency. Interrupt latency arises mainly because of three factors:

2 4 | P a g e

1. Kernel disabling the interrupts to protect the kernel data structures from the interrupt

service routines.

2. Kernels processing time to call the ISR.

3. Device drivers disabling of interrupts because device spin specification required it.

Little can be done about the delay due to third reason delay due to the second reason is very

less as compared to other ones. The interrupt latency in an operating system is majorly related

to the maximum time for which interrupts are disabled by the OS. Therefore one can improve

up on the interrupt latency by focusing on the first reason. Hence in a real time operating

system interrupt should be disabled for minimum possible time. This is in contrast to general

purpose OS like LINUX, where the time for which interrupts remain disabled can be as large

as 500ms.

d) TASKS:

In RT Kernel, a task is a branch of the code that runs concurrently with another tasks from

the programmer's point of view. At the physical level, tasks are actually executed using

processor time sharing. Each task can be considered to be an independent program, which

executes in its own context (processor registers, stack pointer, etc.).

When the currently running task loses its claim for executing (by the issuing of a system call

or interrupt), a context switch is performed. The current context (processor registers, stack

pointer, etc.) is saved and the context of another task is restored. This mechanism in the RT

Kernel is called the "dispatcher".

Generally, there are more than one executable task, and it is necessary to determine the order

of the task switching (execution) by using some rules. "Scheduler" is a mechanism that

controls the order of the task execution.

RT Kernel uses a priority-based scheduling based on a priority level assigned to the each

task. The smaller the value of the priority, the higher is the priority level. RT Kernel uses a 32

levels of priority. Priorities 0 (highest) and 31 (lowest) are reserved by the system for the

internal using. The user may create tasks with priorities 1…30. In RT Kernel, more than one

task can have the same (identical) priority.

2 5 | P a g e

TASK STATES

There are four task states in RT Kernel:

1. RUNNING state

The task is currently executing.

2. READY state

The task is ready to execute, but cannot do so because a task with higher priority (sometimes

same priority) is already executing. A task may execute at any time once the processor

becomes available. In RT Kernel, both RUNNING and READY states are marked as

RUNNABLE.

3. WAIT/SUSPEND state

When a task is in the WAIT/SUSPEND state, the task cannot execute because the conditions

necessary for its execution have not yet been met and the task is waiting for them. When a

task enters the WAIT/SUSPEND state, the task's context is saved. When the task resumes

execution from the WAIT/SUSPEND state, the task's context is restored.

WAIT/SUSPEND actually has one of three types:

- WAITING state

The task execution is blocked until some synchronization action occurs, such as timeout

expiration, semaphore available, event occurring, etc.

- SUSPENDED state

The task is forced to be blocked (switched to the non-executing state) by another task or

itself.

- WAITING_SUSPENDED state

Both WAITING and SUSPENDED states co-exist. In RT Kernel, if a task leaves a

WAITING state, but a SUSPENDED state exists, the task is not switched to the

READY/RUNNING state. Similarly, if a task leaves SUSPENDED state, but a WAITING

state exists, the task is not switched to the READY/RUNNING state. A task is switched to

2 6 | P a g e

READY/RUNNING state only if there are neither WAITING nor SUSPENDED states

flagged on it.

4. DORMANT state

The task has been initialized and it is not yet executing or it has already exited. Newly created

tasks always begin in this

SYSTEM TASKS

In RT Kernel, the task with priority 0 (highest) is used for supporting the system tick timer

functionality and the task with priority 31 (lowest) is used for performing statistics. RT

Kernel automatically creates these tasks at the system start.

6.4 RT Kernel FUNCTIONALITY

a) Tasks

The user may create tasks with priorities 1…30. User tasks should newer communicate with

tasks of priorities 0 and 31 (for instance, to attempt to switch these tasks into suspend state

etc.). The system will reject any attempt to create a task with priority 0 or 31. More than one

user tasks can have the same priority. Tasks with identical priorities have the ability for

round-robin scheduling.

Task functions (RT Kernel)

Function Description

tn_task_create ---------------------Create task

tn_task_terminate -----------------Move task to DORMANT state

tn_task_exit ------------------------Terminate currently running task

tn_task_delete ----------------------Delete already terminated task

tn_task_activate -------------------Activate task. Task is switched from DORMANT state to

running state

tn_task_iactivate------------------ The same as above, but in interrupts

tn_task_change_priority--------- Change current task priority

tn_task_suspend -------------------Suspend task. If task is runnable, it is switched to the

SUSPENDED state.

2 7 | P a g e

If task is in the WAITING stage, it is moved into the WAITING_SUSPENDED state

tn_task_resume-------------------- Resume suspended task - allows the task to continue its

normal processing.

tn_task_sleep ---------------------- Move currently running task sleep.

tn_task_wakeup--------------------- Wake up the task from sleep.

tn_task_iwakeup -----------------The same as above, but in interrupts.

tn_task_release_wait ----------- Forcibly release task from waiting (including sleep), but not

from the SUSPENDED state

tn_task_irelease_wait -----------The same as above, but in interrupts

b) SEMAPHORES:

A semaphore has a resource counter and a wait queue. The resource counter shows the

number of unused resources. The wait queue manages the tasks waiting for resources from

this semaphore. The resource counter is incremented by 1 when a task releases a semaphore

resource, and is decremented by 1 when a task acquires a semaphore resource. If a semaphore

has no available resources (resource counter is 0), a task that requested a resource will wait in

the semaphore wait queue until a resource is arriving (another task releases it to the

semaphore).

Semaphore functions (RT Kernel)

Function Description

tn_sem_create ------------------- Create semaphore

tn_sem_delete -------------------- Delete semaphore

tn_sem_signal -------------------- Release semaphore resource

tn_sem_isignal ------------------- The same as above, but in interrupts

tn_sem_acquire ------------------ Acquire one resource from semaphore

tn_sem_polling ------------------- Acquire one resource from semaphore with polling

tn_sem_ipolling ------------------ The same as above, but in interrupts

c) MUTEXES:

A mutex is an object used for mutual exclusion of a shared resource. Mutex supports two

approaches for avoiding the unbounded priority inversions problem - the priority inheritance

protocol and the priority ceiling protocol. A discussion about strengths and weaknesses of

2 8 | P a g e

each protocol as well as priority inversions problem is beyond the scope of this document. A

mutex has a similar functionality as a semaphore with maximum count = 1(a binary

semaphore). The differences are that a mutex can only be unlocked by the task that locked it

and that a mutex is unlocked by RT Kernel when the locking task terminates.

A mutex uses the priority inheritance protocol when it has been created with the

TN_MUTEX_ATTR_INHERIT attribute, and the priority ceiling protocol when its attribute

value is TN_MUTEX_ATTR_CEILING.

The mutexes in RT Kernel support full-feature priority inheritance protocols according to the

document. RT Kernel uses a full version of priority ceiling protocol. The priority inheritance

protocol solves the priority inversions problem but doesn't prevents deadlocks. The priority

ceiling protocol prevents deadlocks and chained blocking but it is slower than the priority

inheritance protocol .

Mutex functions (RT Kernel)

Function Description

tn_mutex_create ----------------- Create a mutex

tn_mutex_delete ----------------- Delete a mutex

tn_mutex_lock ------------------- Lock a mutex

tn_mutex_lock_polling --------- Try to lock a mutex (with polling)

tn_mutex_unlock ---------------- Unlock a mutex

d)DATA QUEUES:

A data queue is a FIFO that stores pointer (of type void*) in each cell, called a data element.

A data queue also has an associated wait queue each for sending (wait_send queue) and for

receiving (wait_receive queue). A task that sends a data element is tried to put the data

element into the FIFO. If there is no space left in the FIFO, the task is switched to the

WAITING state and placed in the data queue's wait_send queue until space appears (another

task gets a data element from the data queue).

A task that receives a data element tries to get a data element from the FIFO. If the FIFO is

empty (there is no data in the data queue), the task is switched to the WAITING state and

placed in the data queue's wait_receive queue until data element arrive (another task puts

2 9 | P a g e

some data element into the data queue). To use a data queue just for the synchronous message

passing, set size of the FIFO to 0. The data element to be sent and received can be interpreted

as a pointer or an integer and may have value 0 (NULL).

Data Queue functions (RT Kernel)

Function Description

tn_queue_create ------------ Create data queue

tn_queue_delete ------------ Delete data queue

tn_queue_send ------------- Send (put) a data element into the data queue

tn_queue_send_polling --- Try to send(put) a data element into the data queue(with polling)

tn_queue_isend_polling ---The same as above, but inside interrupts

tn_queue_receive ---------- Receive (get) a data element from the data queue

tn_queue_receive_polling -- Try to receive (get) a data element from the data queue (with

polling)

tn_queue_ireceive ----------- The same as above, but inside interrupts

e) EVENTFLAG:

An eventflag has an internal variable (of size integer), which is interpreted as a bit pattern

where each bit represents an event. An eventflag also has a wait queue for the tasks waiting

on these events. A task may set specified bits when an event occurs and may clear specified

bits when necessary. A task waiting for events to occur will wait until every specified bit in

the eventflag bit pattern is set. The tasks waiting for an eventflag are placed in the eventflags

wait queue. An eventflag is a very suitable synchronization object for cases where (for some

reasons) one task has to wait for many tasks, or vice versa, many tasks have to wait for one

task.

Eventflag functions (RT Kernel)

Function Description

tn_event_create------------ Create eventflag

tn_event_delete ----------- Delete eventflag

tn_event_wait -------------- Wait until eventflag satisfies the release condition

tn_event_wait_polling ---- Wait until eventflag satisfies the release condition, with polling

tn_event_iwait -------------- The same as above, but inside interrupts

3 0 | P a g e

tn_event_set ---------------- Set eventflag

tn_event_iset --------------- The same as above, but inside interrupts

tn_event_clear ------------- Clears the bits in the eventflag

tn_event_iclear ------------ The same as above, but inside interrupts

Fixed-Sized Memory Pools

A fixed-sized memory pool is used for managing fixed-sized memory blocks dynamically. A

fixed-sized memory pool has a memory area where fixed-sized memory blocks are allocated

and the wait queue for acquiring a memory block. If there are no free memory blocks, a task

trying to acquire a memory block will be placed into the wait queue until a free memory

block arrives (another task returns it to the memory pool).

Fixed-sized memory pool functions (RT Kernel)

Function Description

tn_fmem_create ------------- Create Fixed-Sized Memory Pool

tn_fmem_delete ------------- Delete Fixed-Sized Memory Pool

tn_fmem_get ----------------- Acquire (get) a memory block from pool

tn_fmem_get_polling-------- Acquire (get) a memory block from pool, with polling

tn_fmem_get_ipolling ------ The same as above, but inside interrupts

tn_fmem_release ------------ Release (put back to pool) a memory block

tn_fmem_irelease ----------- The same as above, but inside interrupts

6.5 RT Kernel TIME TICKS:

For the purpose of calculating timeouts and delays, RT Kernel uses a time tick timer. In RT

Kernel, this time tick timer must to be a some kind of hardware timer that produces interrupt

for time ticks processing. The period of this timer is user determined (usually in the range

0.5...20 ms). Within the time ticks interrupt processing, it is only necessary to call the

tn_tick_int_processing() functions (see details below). To minimize interrupt processing

time, RT Kernel makes the most time consuming processing inside the task with priority 0.

The tn_tick_int_processing() function releases the priority 0 task from sleep (see file tn.c).

3 1 | P a g e

6.6 ROUND ROBIN SCHEDULING IN RT Kernel:

RT Kernel has the ability to make round robin scheduling for tasks with identical priority.

By default, round robin scheduling is turned off for all priorities. To enable round robin

scheduling for tasks on certain priority level and to set time slices for these priority, user must

call the tn_sys_tslice_ticks() function. The time slice value is the same for all tasks with

identical priority but may be different for each priority level.

If the round robin scheduling is enabled, every system time tick interrupt increments the

currently running task time slice counter.

When the time slice interval is completed, the task is placed at the tail of the ready to run

queue of its priority level (this queue contains tasks in the RUNNABLE state) and the time

slice counter is cleared. Then the task may be preempted by tasks of higher or equal priority.

If tasks with round-robin scheduling never switch to the WAITING state (for instance when

there are no semaphore(s) acquiring, sleep,etc.), lower priority tasks will never run ! In most

cases, there is no reason to enable round robin scheduling. For applications running multiple

copies of the same code, however, (GUI windows, etc.), round robin scheduling is an

acceptable solution.

3 2 | P a g e

7. TECHNICAL SPECIFICATIONS

7.1 Software Requirements :

Keil uvision4 IDE (32K code limited version.)

CooCox CoIDE (Unlimited, open source)

GCC based open source tool chains

7.2 Hardware Model:

i) LPC17xx HPLUS Ex Board:

(Features : USB Device and Host Connectivity Options , Ethernet with DP83848 PHY MAC,

SDCard (Micro) Interface , RS232 Interface for UART0 and UART3 , Analog input via

ADC0.5, Unused I/O pinouts , OnBoard Reset and ISP Switches , On Board Power Supply

Circuit for +5V and +3.3V (USB or external Power Source input options) , On Board 12

MHz Clock , 32.768 KHz Clock for RTC , Option for a CMOS Battery , Onboard 20 pin

JTAG connector for debugging/programming applications , On board TFT Connector for

3.2inch TFT (with touch and without touch) , On Board Graphical LCD Connector , LED for

Power Supply, USB, Ethernet and Test LED. )

ii) Graphical LCD TM12864H6CCOWA

(Features : Driver IC: NT75451 Data Interface Parallel mode (Number of Pixels: 128 x 64 ,

3.2inch TFT Connectivity)

iii) Plugins/Programmers: H-JTAG, CooCox Colink, Flash Magic.

Power Supply : +5v , 500mA Regulated Power Supply , 3.3v for LPC 1768

3 3 | P a g e

8. LPC 1768

Figure 8- Model object of LPC1768 from Coinel Technologies

8.1 GENERAL DESCRIPTION:

The LPC1768 are ARM Cortex-M3 based microcontrollers for embedded applications

featuring a high level of integration and low power consumption. The ARM Cortex-M3 is a

next generation core that offers system enhancements such as enhanced debug features and a

higher level of support block integration.

The LPC1768 operate at CPU frequencies of up to 100 MHz. The LPC1769 operates at CPU

frequencies of up to 120 MHz. The ARM Cortex-M3 CPU incorporates a 3-stage pipeline

and uses a Harvard architecture with separate local Instruction and data buses as well as a

third bus for peripherals. The ARM Cortex-M3 CPU also includes an internal prefetch unit

that supports speculative branching.

The peripheral complement of the LPC1768 includes up to 512 kB of flash memory, up to 64

kB of data memory, Ethernet MAC, USB Device/Host/OTG interface, 8-channel general

3 4 | P a g e

purpose DMA controller, 4 UARTs, 2 CAN channels, 2 SSP controllers, SPI interface, 3 I2C-

bus interfaces, 2-input plus 2-output I2S-bus interface, 8-channel 12-bit ADC, 10-bit DAC,

motor control PWM, Quadrature Encoder interface, four general purpose timers, 6-output

general purpose PWM, ultra-low power Real-Time Clock (RTC) with separate battery

supply, and up to 70 general purpose I/O pins.

8.2 FEATURES AND BENEFITS:

ARM Cortex-M3 processor, running at frequencies of up to 100 MHz (LPC1768) or of up to

120 MHz (LPC1769). A Memory Protection Unit (MPU) supporting eight regions is

included.

ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).

Up to 512 kB on-chip flash programming memory. Enhanced flash memory

accelerator enables high-speed 120 MHz operation with zero wait states.

In-System Programming (ISP) and In-Application Programming (IAP) via on-chip

bootloader software.

On-chip SRAM includes:

32/16 kB of SRAM on the CPU with local code/data bus for high-performance

CPU access.

Two/one 16 kB SRAM blocks with separate access paths for higher

throughput.These SRAM blocks may be used for Ethernet, USB, and DMA

memory, as well asfor general purpose CPU instruction and data storage.

Eight channel General Purpose DMA controller (GPDMA) on the AHB

multilayer matrix that can be used with SSP, I2S-bus, UART, Analog-to-

Digital and Digital-to-Analog converter peripherals, timer match signals, and

for memory-to-memory transfers.

Multilayer AHB matrix interconnect provides a separate bus for each AHB

master. AHB masters include the CPU, General Purpose DMA controller,

Ethernet MAC, and the USB interface. This interconnect provides

communication with no arbitration delays.

Split APB bus allows high throughput with few stalls between the CPU and

DMA.Serial interfaces:Ethernet MAC with RMII interface and dedicated

DMA controller. (Not available on all parts).USB 2.0 full-speed

3 5 | P a g e

device/Host/OTG controller with dedicated DMA controller and on-chip PHY

for device, Host, and OTG functions.

Four UARTs with fractional baud rate generation, internal FIFO, and DMA

support.

One UART has modem control I/O and RS-485/EIA-485 support, and one

UART has IrDA support.

CAN 2.0B controller with two channels.

SPI controller with synchronous, serial, full duplex communication and

programmable data length.

Two SSP controllers with FIFO and multi-protocol capabilities. The SSP

interfaces can be used with the GPDMA controller.

Three enhanced I2C bus interfaces, one with an open-drain output supporting

full I2C specification and Fast mode plus with data rates of 1 Mbit/s, two with

standard port pins. Enhancements include multiple address recognition and

monitor mode.

I2S (Inter-IC Sound) interface for digital audio input or output, with fractional

rate control. The I2S-bus interface can be used with the GPDMA. The I2S-bus

interface supports 3-wire and 4-wire data transmit and receive as well as

master clock input/output.

Other peripherals:

70 (100 pin package) General Purpose I/O (GPIO) pins with configurable pull-

up/down resistors. All GPIOs support a new, configurable open-drain operating mode.

The GPIO block is accessed through the AHB multilayer bus for fast access and

located in memory such that it supports Cortex-M3 bit banding and use by the

General Purpose DMA Controller.

12-bit Analog-to-Digital Converter (ADC) with input multiplexing among eight pins,

conversion rates up to 200 kHz, and multiple result registers. The 12-bit ADC can be

used with the GPDMA controller. 10-bit Digital-to-Analog Converter (DAC) with

dedicated conversion timer and DMA support.

Four general purpose timers/counters, with a total of eight capture inputs and ten

compare outputs. Each timer block has an external count input. Specific timer events

can be selected to generate DMA requests.

3 6 | P a g e

One motor control PWM with support for three-phase motor control.

Quadrature encoder interface that can monitor one external quadrature encoder.

One standard PWM/timer block with external count input.

RTC with a separate power domain and dedicated RTC oscillator. The RTC block

includes 20 bytes of battery-powered backup registers.

WatchDog Timer (WDT). The WDT can be clocked from the internal RC oscillator,

the RTC oscillator, or the APB clock.

ARM Cortex-M3 system tick timer, including an external clock input option.

Repetitive interrupt timer provides programmable and repeating timed interrupts.

Each peripheral has its own clock divider for further power savings.

Standard JTAG test/debug interface for compatibility with existing tools. Serial Wire

Debug and Serial Wire Trace Port options.

Emulation trace module enables non-intrusive, high-speed real-time tracing of

instruction execution.

Integrated PMU (Power Management Unit) automatically adjusts internal regulators

to minimize power consumption during Sleep, Deep sleep, Power-down, and Deep

power-down modes.

Four reduced power modes: Sleep, Deep-sleep, Power-down, and Deep power-down.

Single 3.3 V power supply (2.4 V to 3.6 V).

Four external interrupt inputs configurable as edge/level sensitive. All pins on Port 0

and Port 2 can be used as edge sensitive interrupt sources.

Non-maskable Interrupt (NMI) input.

Clock output function that can reflect the main oscillator clock, IRC clock, RTC

clock,

CPU clock, and the USB clock.

The Wake-up Interrupt Controller (WIC) allows the CPU to automatically wake up

from any priority interrupt that can occur while the clocks are stopped in deep sleep,

Power-down, and Deep power-down modes.

Processor wake-up from Power-down mode via any interrupt able to operate during

Power-down mode (includes external interrupts, RTC interrupt, USB activity,

Ethernet wake-up interrupt, CAN bus activity, Port 0/2 pin interrupt, and NMI).

Brownout detect with separate threshold for interrupt and forced reset.

Power-On Reset (POR).

3 7 | P a g e

Crystal oscillator with an operating range of 1 MHz to 25 MHz.

4 MHz internal RC oscillator trimmed to 1 % accuracy that can optionally be used as

a system clock.

PLL allows CPU operation up to the maximum CPU rate without the need for a high-

frequency crystal. May be run from the main oscillator, the internal RC oscillator, or

the RTC oscillator.

USB PLL for added flexibility.

Code Read Protection (CRP) with different security levels.

Unique device serial number for identification purposes.

Available as LQFP100 (14 mm 14 mm 1.4 mm) and TFBGA1001 (9 mm 9

mm -0.7 mm) package.

3 8 | P a g e

8.3 ARCHITECTURE OF CORTEX M3

Figure 8.3- Block diagram of Cortex M3

8.4 FUNCTIONAL DESCRIPTION:

a) Architectural overview :

The ARM Cortex-M3 includes three AHB-Lite buses: the system bus, the I-code bus, and the

D-code bus (see Figure 1). The I-code and D-code core buses are faster than the system bus

and are used similarly to TCM interfaces: one bus dedicated for instruction fetch (I-code) and

one bus for data access (D-code). The use of two core buses allows for simultaneous

3 9 | P a g e

operations if concurrent operations target different devices. The LPC17xx use a multi-layer

AHB matrix to connect the ARM Cortex-M3 buses and other bus masters to peripherals in

a flexible manner that optimizes performance by allowing peripherals that are on different

slaves ports of the matrix to be accessed simultaneously by different bus masters.

b) ARM Cortex-M3 processor :

The ARM Cortex-M3 is a general purpose, 32-bit microprocessor, which offers high

performance and very low power consumption. The ARM Cortex-M3 offers many new

features, including a Thumb-2 instruction set, low interrupt latency, hardware divide,

interruptible/continual multiple load and store instructions, automatic state save and restore

for interrupts, tightly integrated interrupt controller with wake-up interrupt controller, and

multiple core buses capable of simultaneous accesses. Pipeline techniques are employed so

that all parts of the processing and memory systems can operate continuously. Typically,

while one instruction is being executed, its successor is being decoded, and a third instruction

is being fetched from memory.

c) On-chip flash program memory :

The LPC17xx contain up to 512 kB of on-chip flash memory. A new two-port flash

accelerator maximizes performance for use with the two fast AHB-Lite buses.

d) On-chip SRAM

The LPC17xx contain a total of 64 kB on-chip static RAM memory. This includes the main

32 kB SRAM, accessible by the CPU and DMA controller on a higher-speed bus, and two

additional 16 kB each SRAM blocks situated on a separate slave port on the AHB multilayer

matrix. This architecture allows CPU and DMA accesses to be spread over three separate

RAMs that can be accessed simultaneously.

e) Memory Protection Unit (MPU)

The LPC17xx have a Memory Protection Unit (MPU) which can be used to improve the

reliability of an embedded system by protecting critical data within the user application.

4 0 | P a g e

32-bit ARM Cortex-M3 microcontroller

The MPU allows separating processing tasks by disallowing access to each other's data,

disabling access to memory regions, allowing memory regions to be defined as read-only and

detecting unexpected memory accesses that could potentially break the system. The MPU

separates the memory into distinct regions and implements protection by preventing

disallowed accesses. The MPU supports up to 8 regions each of which can be divided into 8

subregions. Accesses to memory locations that are not defined in the MPU regions, or not

permitted by the region setting, will cause the Memory Management Fault exception to take

place.

f) Memory map

The LPC17xx incorporates several distinct memory regions with the overall map of the entire

address space from the user program viewpoint following reset. The interrupt vector area

supports address remapping. The AHB peripheral area is 2 MB in size and is divided to allow

for up to 128 peripherals. The APB peripheral area is 1 MB in size and is divided to allow for

up to 64 peripherals. Each peripheral of either type is allocated 16 kB of space. This allows

simplifying the address decoding for each peripheral.

g) Nested Vectored Interrupt Controller (NVIC)

The NVIC is an integral part of the Cortex-M3. The tight coupling to the CPU allows for low

interrupt latency and efficient processing of late arriving interrupts.

Features

• Controls system exceptions and peripheral interrupts

• In the LPC17xx, the NVIC supports 33 vectored interrupts

• 32 programmable interrupt priority levels, with hardware priority level masking

• Relocatable vector table

• Non-Maskable Interrupt (NMI)

• Software interrupt generation

h) Interrupt sources

Each peripheral device has one interrupt line connected to the NVIC but may have several

interrupt flags. Individual interrupt flags may also represent more than one interrupt source.

4 1 | P a g e

Any pin on Port 0 and Port 2 (total of 42 pins) regardless of the selected function, can be

programmed to generate an interrupt on a rising edge, a falling edge, or both.

General purpose 32-bit timers/external event counters

The LPC17xx include four 32-bit timer/counters. The timer/counter is designed to count

cycles of the system derived clock or an externally-supplied clock. It can optionally generate

interrupts, generate timed DMA requests, or perform other actions at specified timer values,

based on four match registers. Each timer/counter also includes two capture inputs to trap the

timer value when an input signal transitions, optionally generating an interrupt.

Features

• A 32-bit timer/counter with a programmable 32-bit prescaler.

• Counter or timer operation.

• Two 32-bit capture channels per timer, that can take a snapshot of the timer value

when an input signal transitions. A capture event may also generate an interrupt.

• Four 32-bit match registers that allow:

– Continuous operation with optional interrupt generation on match.

– Stop timer on match with optional interrupt generation.

– Reset timer on match with optional interrupt generation

• Up to four external outputs corresponding to match registers, with the following

capabilities:

– Set LOW on match.

– Set HIGH on match.

– Toggle on match.

– Do nothing on match.

• Up to two match registers can be used to generate timed DMA requests.

4 2 | P a g e

9. Clocking and Power Control

Crystal oscillators

The LPC17xx include three independent oscillators. These are the main oscillator, the IRC

oscillator, and the RTC oscillator. Each oscillator can be used for more than one purpose as

required in a particular application. Any of the three clock sources can be chosen by software

to drive the main PLL and ultimately the CPU. Following reset, the LPC17xx will operate

from the Internal RC oscillator until switched by software. This allows systems to operate

without any external crystal and the bootloader code to operate at a known frequency.

Figure 9- Block Diagram of Clocking and Power Control

4 3 | P a g e

10. Graphical LCD

Figure 10.a- Model object of Graphical LCD TM12864H6CCOWA

INTERNAL BLOCK DIAGRAM :

Figure 10.b- Internal Block diagram of TM12864HCCOWA

4 4 | P a g e

10.1 Description

The TM12864H6CCOWA, Graphics LCD unit consists of 128 (segment) x 64 (common)

dots dot-matrix LCD panel, NT75451 is a single-chip dot matrix LCD driver that can be

connected directly to a microprocessor bus.

Wide Operating temperature.

Requirements on environmental protection: RoHS.

The 128x64 Character LCDs have their own limitations; they can only display characters of

certain dimensions. The Graphical LCDs are thus used to display customized characters and

images. The Graphical LCDs find use in many applications; they are used in video games,

mobile phones, lifts etc. as display units.

Various graphical LCDs are available in the market with different sizes.

Here JHD12864E Graphical LCD has been explained. This LCD has a display format

of 128x64 dots and has yellow-green colour backlight. Each LCD needs a controller to

execute its internal operations. This LCD uses two KS0108 controllers.

10.2 PAGING SCHEME OF GRAPHICAL LCD :

The 128x64 LCD is divided into two equal halves with each half being controlled by a

separate KS0108 controller. Such LCDs (using KS0108 controller) involve paging scheme,

i.e., whole LCD is divided equally into pages. The paging scheme of the graphical LCD can

be easily understood from the following table.

4 5 | P a g e

Figure 10.2.a- Paging scheme of TM12864HCCOWA

1. 128x64 LCD implies 128 columns and 64 rows. In total there are (128x64 = 1024) pixels.

2. 128x64 LCD is divided equally into two halves. Each half is controlled by a separate

controller and consists of 8 pages. In above diagram, CS stands for Controller Select.

3. Each page consists of 8 rows and 64 columns. So two horizontal pages make 128 (64x2)

columns and 8 vertical pages make 64 rows (8x8).

PIN DESCRIPTION :

Figure 10.2.b- Pin configuration of TM12864HCCOWA

4 6 | P a g e

BLOCK DIAGRAM:

Figure 10.2.c- Block diagram of TM12864HCCOWA

4 7 | P a g e

11. Universal Asynchronous Receiver/Transmitter

A Universal Asynchronous Receiver/Transmitter, abbreviated UART is a type of

"asynchronous receiver/transmitter", a piece of computer hardware that translates data

between parallel and serial forms. UARTs are commonly used in conjunction with

communication standards such as EIA, RS-232, RS-422 or RS-485. The universal

designation indicates that the data format and transmission speeds are configurable and that

the actual electric signaling levels and methods (such as differential signaling etc.) typically

are handled by a special driver circuit external to the UART.

A UART is usually an individual (or part of an) integrated circuit used for serial

communications over a computer or peripheral device serial port. UARTs are now commonly

included in microcontrollers. A dual UART, or DUART, combines two UARTs into a single

chip. Many modern ICs now come with a UART that can also communicate synchronously;

these devices are called USARTs (universal synchronous/asynchronous receiver/transmitter).

11.1 UART Module Descriptions

The UART core consists of five modules:

• Transmitter

• Receiver

• Modem interface

• Baud generator

• Interrupt controller

a) UART Transmitter

To send data with the UART, the processor writes data to the transmitter address as if it was a

memory space.The transmitter controls the entire transmission process. The transmitter

performs parallel-to-serial conversions, and sends data on the serial line. The processor

pushes data (5 to 8 bits wide) into the transmit FIFO, which is 256 bytes deep. The

transmitter pops the data off the FIFO, and shifts it out at the baud rate. The Divisor Registers

determine the baud rate. Using the Line Control Register, the user can configure the number

of data bits (5, 6, 7, or 8) per frame, as well as the number of stop bits (1, 1.5, or 2) to be sent

4 8 | P a g e

at the end of a frame. The transmitter also has a parity generation circuit that is capable of

creating even, odd, stick even, or stick odd parity. When parity generation is disabled, no

parity will be sent after the data bits.

There is one interrupt associated with the transmitter—it is a third-level priority interrupt that

occurs when the transmit FIFO is empty.

Logically, the transmitter performs the following steps:

1. If there is data available in the FIFO, loads a byte into the shift register.

2. Sends a start bit on the serial line, indicating the beginning of a frame.

3. Shifts out data bits from the shift register to the serial line.

4. If parity is enabled, sends a Parity Bit after all data bits are sent.

5. Sends stop bit(s) on the serial line, indicating the end of a frame.

b) UART Receiver

To receive data with the UART, the processor reads data from the receiver address as if it

was a memory space. The receiver is responsible for capturing data from the serial line and

validating data integrity. The receiver performs serial-to-parallel conversions, and pushes

data into the receive FIFO at the baud rate. The processor can pop data from the 256-byte

deep receive FIFO at the system clock frequency. The supplied RCLK must be 16 times

faster than the baud rate. The receiver monitors the serial line. When a valid start bit is

detected, the receiver begins to shift data bits from the serial line, and saves the received data

in the receive FIFO. Using the Line Control Register, the user can configure the number of

data bits (5, 6, 7, or 8) per frame, as well as the type of parity to expect on the serial line. The

receiver has a parity generation circuit that is capable of creating even, odd, stick even, or

stick odd parity as data is shifted in from the serial line. The calculated parity is then checked

with the received parity to determine data integrity. When parity generation is disabled, no

parity will be expected after the data bits.

Besides parity errors, the receiver is also capable of detecting frame errors, overrun errors,

and break errors. Frame errors occur when the receiver is expecting a stop bit but received a

'0' on the serial line. Overrun errors occur when the receive FIFO is full and the newly

received data is destroyed because it cannot be saved in the FIFO. Break errors occur when

4 9 | P a g e

the serial line is '0' for more than a full frame. Break errors, frame errors, and parity errors are

associated with the particular pieces of data in the FIFO that contains the errors. LSR

indicates if there are any errors in the entire receive FIFO.

In addition to error detection capabilities, the receiver also features false start bit detection

and self-recovery from frame error. The serial line may be subject to noise, so it is essential

that the receiver be able to differentiate noise from a valid start bit. For the receiver to

recognize a '0' on the serial line as a valid start bit, this '0' value must remain for at least half a

baud cycle from the falling edge of the serial input. If the start bit does not remain stable in

that period, it is discarded and the receiver will return to its idle state.

The asynchronous nature of a serial line means it is possible that the receiver is out of synch

from the transmitter, resulting in a frame error. When a frame error occurs, the receiver tries

to resynchronize itself to the transmitter. To achieve this self-recovery feature, the receiver

assumes that the invalid stop bit is actually the start bit of the next frame, and proceeds to

shift in data bits from the serial line. There are three interrupts associated with the receiver.

The highest-level priority interrupt occurs when they received data has an error. A second-

level priority interrupt occurs when the receive FIFO has reached its trigger level. Another

second-level priority interrupt is the timeout interrupt, which occurs when data is sitting idle

in the receive FIFO for over a certain period of time.

To perform all these functionalities, the receiver performs the following steps:

1. Hunts for a valid start bit, which indicates the beginning of a frame.

2. Shifts in data bits from the serial line to the shift register.

3. If parity is enabled, compares received parity bit with the expected value.

4. Checks for a valid stop bit on the serial line, which indicates the end of a frame.

c) Modem Interface

The modem interface allows the processor to transmit data to another terminal, or handshake

to the modem input signals. It also makes the modem's status available to the processor. The

Modem Status Register reports status information in two ways. It shows the values of DCDn,

Rin, DSRn,vand CTSn signals from the modem, and it also indicates whether any of those

5 0 | P a g e

signals have changed since the last time it was read by the processor. The user can drive the

values of OUTn1, OUTn2, RTSn, and DTRn via the Modem Control Register.

d)Baud Generator

The baud generator is capable of creating a clock by dividing the system clock by any divisor

from 2 to 216-1. The divisor is the unsigned value stored in the Divisor Register. The output

frequency of the baud generator is 16 times the baud rate. This means, the Divisor Register

must hold a value equal to the system clock divided by baud rate and further divided by 16.

This output clock can be used as the receive reference clock by the receiving UART.

e)Interrupt Controller

The interrupt controller works with the transmitter, receiver, and modem interface to notify

the processor of events that require intervention. The user can configure which interrupts to

enable or disable via the Interrupt Enable Register (IER). When the processor is interrupted,

it can find out more details regarding the interrupt by reading the Interrupt Identification

Register (IIR). The interrupt controller monitors internal interrupt request lines from other

modules. These internal interrupts are masked with the IER. The interrupt controller is then

able to determine the interrupt pending with highest priority, and report it in the IIR. After the

interrupt has been serviced, the interrupt controller clears the interrupt request and updates

the IIR accordingly.

11.2 UART Architecture

The UART core consists of a transmitter, a receiver, a modem interface, a baud generator, an

interrupt controller, and various control and status registers. The transmitter and receiver

perform parallel-toserial and serial-to-parallel conversions, respectively. Each has a 256-byte

FIFO to buffer data flow. The use of FIFO buffers increases the overall transmission rate by

allowing slower processors to respond, and reducing the amount of time wasted on context

switching. Besides data transfer, they also facilitate start/stop framing bits, check various

parity options, as well as detect transmission errors.

The modem interface allows the processor to transmit data to another terminal or handshake

to the modem input signals. It also makes the modem's status available to the processor. The

5 1 | P a g e

baud generator creates a baud rate clock and a receiver reference clock. The interrupt

controller works with the transmitter, receiver, and modem interface to notify the processor

of events that require intervention. Some examples of these events are transmission errors and

modem status changes.

The processor has access to the complete status of the UART at any time. Information

reported includes the line condition, modem status, as well as any errors such as parity,

overrun, framing, or line break. The processor can also configure the UART's operation via

various control registers.

Figure 11.2.a- UART Core architecture

5 2 | P a g e

Figure 11.2.b- Pin description of UART

5 3 | P a g e

Figure 11.2.c- Port description of UART modem

11.3 UART Standard Serial Data Format

Standard UART characters are contained within frames consisting of start/stop indicators,

data, and parity information. The serial bit stream uses the following sequence:

• Start bit

• Data bits

• Parity bit (if enabled)

• Stop bit(s)

When there is nothing to be sent, the serial line is high. The first low bit is the start bit, which

indicates the beginning of a new frame. The next five to eight bits are data bits, which convey

the actual information to be sent, least significant bit first. The number of data bits per frame

is configurable. If enabled, a parity bit will be sent on the serial line after the data bits.

Finally, the serial line is held high again for at least one bit to indicate the end of a frame.

This is called the stop bit, which also returns the serial line to the idle state.

Figure 11.3.a- Standard Serial Data Format of UART

5 4 | P a g e

12. PORTING PROCESS

12.1 Porting the RT-Kernel:

The RTX Real-Time Kernel is an easy-to-use real-time executive for microcontrollers that

provides a real-time operating system (RTOS) for ARM7, ARM9, and Cortex-M3 devices.

The RTOS handles any common tasks such as scheduling, maintenance, and timing issues so

that they are invisible to the end user. The RTX Real-Time Kernel is a powerful RTOS that

works with a wide variety of ARM derivatives.

12.2 Objective:

The objective of this process is to demonstrate how to port the RTX Real-Time Kernel to the

LPC1768. Once the proper configuration files are generated, a simple program using various

OS task functions that can blink the onboard LEDs is programmed to the target and used to

verify proper operation of the OS.

12.2 (a) Creating the New Project:

o Start the Keil μVision environment.

o Open the Project menu and select New μVision Project….

o In the Create New Project window, select a new directory for your project, enter a

name for your project, and click Save.

[Figure 12.2.a.a- Create project window in Keil uVision]

5 5 | P a g e

Select the NXP LPC1768 in the CPU vendor database list and click OK.

Figure 12.2.a.b- Device selection window

When the prompt to Copy NXP LPC1768 Startup Code to the Project Folder and Add

File to Project? Appears, click Yes.

Figure 12.2.a.c- Startup Code window

To configure the target, click on the icon in the build toolbar or right-click on

the target, Target 1, in the Project Workspace window and select Manage

Components.

In the Project Components tab, double-click on Target 1. Change the name of the

target toLPC3180 Ext Memory. The Keil μVision environment allows multiple

targets within a single project. Therefore, it is important to label your targets with

5 6 | P a g e

descriptive names. For example, if you were to create a target within this project that

is set up to run only in internal memory, a name like LPC3180 Int Memory helps

you distinguish the proper target for execution.

Figure 12.2.a.d-Configuring Components, Environments and Books

Double-click on Source Group 1 in the Groups window and change the name of the

group to Startup Code.

Add more groups by selecting the New(Insert) icon in the Groups window.

Name the new groups System Calls and Source Code.

5 7 | P a g e

Figure 12.2.a.e-Configuring Components, Environments and Books

Click OK. This brings you back to the Project Workspace window.

b) SETTING THE OPTIONS FOR THE TARGET:

Be aware that the following settings are specific to the LPC1768. For other targets,

consult your hardware manual to determine the appropriate settings.

Configure the project to use the RTX Real-Time Kernel by selecting the Options for

Target icon on the build toolbar or right-clicking on the LPC1768 Ext

Memory target in the Project Workspace window and select Options for the Target

―LPC1768 Ext Memory.‖In the Target tab, be sure that Xtal is set to 12.0 MHz, and

Read/Only Memory Areas off-chipROM1 and Read/Write Memory Areas off-

chip RAM1 are checked. Set the Memory Areas Start and Size as shown below.

5 8 | P a g e

Set the Code Generation for Thumb-Mode, make sure Cross-Module Optimization is

checked.

Figure 12.2.b-Configuring Target1

Make sure to select RTX Kernel for the Operating system.

c)Configuring the Output:

Figure 12.2.c.a-Configuring output

5 9 | P a g e

In the Output tab, make sure the Create Executable and Browse

Information options are checked. Set the Name of Executable to rtkernel.

Click on the Select Folder for Objects button and browse to your project directory.

Click on the Create a new folder button and name the

folder RTKERNEL. Double-click the RTKERNEL folder to open it and click OK.

Configure the linker, asm options for the target file.

Figure 12.2.c.b-Configuring linker, asm options for the target

d) Configuring the Debugging Options:

In the Debug tab, select the use CooCox Debugger option

6 0 | P a g e

Figure 12.2.d.a-Configuring debugging options

Change the utilities options.

.

Figure 12.2.d.b-Change options for utilities

6 1 | P a g e

e) Compilation and generation of hex file

Compile the code and generate the hex file to be ported on to LPC1768.

Figure 12.2.e.a-Compilation and generation of Hex file

6 2 | P a g e

Use the Flash Magic Tool to dump the hex file.

Figure 12.2.e.b-Implementing Hex to LPC1768 using Flash Magic

6 3 | P a g e

13. CODE

GRAPHICAL LCD CODE:

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

Function Name : main()

Description : To initialise system.

Input : none

Output : int

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

*/

S32 main()

{

unsigned char flag = 0;

SystemInit();

HardwareInit();

delay(100000);delay(100000);delay(100000);

LCD_INIT();

LCD_CLEAR();

LCD_SET_PAGE(PAGE1 + 0 , COL1);

lcd_display_string("DESIGN AND IMPLEMENTATION ");

LCD_SET_PAGE(PAGE1 + 2 , COL1);

lcd_display_string("OF GLCD ON CORTEX M3 ");

LCD_SET_PAGE(PAGE1 + 4, COL1);

lcd_display_string("workin’!! ");

LCD_SET_PAGE(PAGE1 + 6, COL1);

lcd_display_string("MANOJ,KISHORE,POSANI");

delay(100000);delay(100000);delay(100000);

while(1)

{

switch(flag)

{

case 0:

flag = 1;

LCD_CLEAR();

LCD_SET_PAGE(PAGE1 + 0 , COL1);

lcd_display_string("DESIGN AND IMPLEMENT");

break;

case 1:

flag = 2;

LCD_SET_PAGE(PAGE1 + 2 , COL1);

lcd_display_string("OF GLCD ON CORTEX M3");

break;

case 2:

6 4 | P a g e

flag = 3;

LCD_SET_PAGE(PAGE1 + 4, COL1);

lcd_display_string("kathakkkk!! ");

break;

case 3:

flag = 0;

LCD_SET_PAGE(PAGE1 + 6, COL1);

lcd_display_string("MANOJ,KISHORE,POSANI");

break;

default:

break;

}

delay(100000);delay(100000);delay(100000);

}

}

UART CODE /***************************************************************************

* uart.c: UART API file for NXP LPC17xx Family Microprocessors

*

*

******************************************************************************/

#include "lpc17xx.h"

#include "type.h"

#include "uart.h"

volatile uint32_t UART3Status, UART1Status,UART0Status;

volatile uint8_t UART3TxEmpty = 1, UART1TxEmpty = 1,UART0TxEmpty = 1;

volatile uint8_t UART3Buffer[BUFSIZE], UART1Buffer[BUFSIZE],UART0Buffer[BUFSIZE];

volatile uint32_t UART3Count = 0, UART1Count = 0,UART0Count = 0;

/*****************************************************************************

** Function name: UART3_IRQHandler

**

** Descriptions: UART3 interrupt handler

**

** parameters: None

** Returned value: None

**

*****************************************************************************/

void UART3_IRQHandler (void)

6 5 | P a g e

{

uint8_t IIRValue, LSRValue;

uint8_t Dummy = Dummy;

IIRValue = LPC_UART3->IIR;

IIRValue >>= 1; /* skip pending bit in IIR */

IIRValue &= 0x07; /* check bit 1~3, interrupt identification */

if ( IIRValue == IIR_RLS ) /* Receive Line Status */

{

LSRValue = LPC_UART3->LSR;

/* Receive Line Status */

if ( LSRValue & (LSR_OE|LSR_PE|LSR_FE|LSR_RXFE|LSR_BI) )

{

/* There are errors or break interrupt */

/* Read LSR will clear the interrupt */

UART3Status = LSRValue;

Dummy = LPC_UART3->RBR; /* Dummy read on RX to clear

interrupt, then bail out */

return;

}

if ( LSRValue & LSR_RDR ) /* Receive Data Ready */

{

/* If no error on RLS, normal ready, save into the data buffer. */

/* Note: read RBR will clear the interrupt */

UART3Buffer[UART3Count] = LPC_UART3->RBR;

UART3Count++;

if ( UART3Count == BUFSIZE )

{

UART3Count = 0; /* buffer overflow */

}

}

}

else if ( IIRValue == IIR_RDA ) /* Receive Data Available */

{

/* Receive Data Available */

UART3Buffer[UART3Count] = LPC_UART3->RBR;

UART3Count++;

if ( UART3Count == BUFSIZE )

{

UART3Count = 0; /* buffer overflow */

}

}

else if ( IIRValue == IIR_CTI ) /* Character timeout indicator */

6 6 | P a g e

{

/* Character Time-out indicator */

UART3Status |= 0x100; /* Bit 9 as the CTI error */

}

else if ( IIRValue == IIR_THRE ) /* THRE, transmit holding register empty */

{

/* THRE interrupt */

LSRValue = LPC_UART3->LSR; /* Check status in the LSR to see if

valid data in U0THR or not

*/

if ( LSRValue & LSR_THRE )

{

UART3TxEmpty = 1;

}

else

{

UART3TxEmpty = 0;

}

}

}

/*****************************************************************************

** Function name: UART1_IRQHandler

**

** Descriptions: UART1 interrupt handler

**

** parameters: None

** Returned value: None

**

*****************************************************************************/

void UART1_IRQHandler (void)

{

uint8_t IIRValue, LSRValue;

uint8_t Dummy = Dummy;

IIRValue = LPC_UART1->IIR;

IIRValue >>= 1; /* skip pending bit in IIR */

IIRValue &= 0x07; /* check bit 1~3, interrupt identification */

if ( IIRValue == IIR_RLS ) /* Receive Line Status */

{

LSRValue = LPC_UART1->LSR;

/* Receive Line Status */

if ( LSRValue & (LSR_OE|LSR_PE|LSR_FE|LSR_RXFE|LSR_BI) )

{

/* There are errors or break interrupt */

/* Read LSR will clear the interrupt */

6 7 | P a g e

UART1Status = LSRValue;

Dummy = LPC_UART1->RBR; /* Dummy read on RX to clear

interrupt, then bail out */

return;

}

if ( LSRValue & LSR_RDR ) /* Receive Data Ready */

{

/* If no error on RLS, normal ready, save into the data buffer. */

/* Note: read RBR will clear the interrupt */

UART1Buffer[UART1Count] = LPC_UART1->RBR;

UART1Count++;

if ( UART1Count == BUFSIZE )

{

UART1Count = 0; /* buffer overflow */

}

}

}

else if ( IIRValue == IIR_RDA ) /* Receive Data Available */

{

/* Receive Data Available */

UART1Buffer[UART1Count] = LPC_UART1->RBR;

UART1Count++;

if ( UART1Count == BUFSIZE )

{

UART1Count = 0; /* buffer overflow */

}

}

else if ( IIRValue == IIR_CTI ) /* Character timeout indicator */

{

/* Character Time-out indicator */

UART1Status |= 0x100; /* Bit 9 as the CTI error */

}

else if ( IIRValue == IIR_THRE ) /* THRE, transmit holding register empty */

{

/* THRE interrupt */

LSRValue = LPC_UART1->LSR; /* Check status in the LSR to see if

valid data in U0THR or not */

if ( LSRValue & LSR_THRE )

{

UART1TxEmpty = 1;

}

6 8 | P a g e

else

{

UART1TxEmpty = 0;

}

}

}

/*****************************************************************************

** Function name: UART0_IRQHandler

**

** Descriptions: UART0 interrupt handler

**

** parameters: None

** Returned value: None

**

*****************************************************************************/

void UART0_IRQHandler (void)

{

uint8_t IIRValue, LSRValue;

uint8_t Dummy = Dummy;

IIRValue = LPC_UART0->IIR;

IIRValue >>= 1; /* skip pending bit in IIR */

IIRValue &= 0x07; /* check bit 1~3, interrupt identification */

if ( IIRValue == IIR_RLS ) /* Receive Line Status */

{

LSRValue = LPC_UART0->LSR;

/* Receive Line Status */

if ( LSRValue & (LSR_OE|LSR_PE|LSR_FE|LSR_RXFE|LSR_BI) )

{

/* There are errors or break interrupt */

/* Read LSR will clear the interrupt */

UART0Status = LSRValue;

Dummy = LPC_UART0->RBR; /* Dummy read on RX to clear

interrupt, then bail out */

return;

}

if ( LSRValue & LSR_RDR ) /* Receive Data Ready */

{

/* If no error on RLS, normal ready, save into the data buffer. */

/* Note: read RBR will clear the interrupt */

UART0Buffer[UART0Count] = LPC_UART0->RBR;

UART0Count++;

if ( UART0Count == BUFSIZE )

{

6 9 | P a g e

UART0Count = 0; /* buffer overflow */

}

}

}

else if ( IIRValue == IIR_RDA ) /* Receive Data Available */

{

/* Receive Data Available */

UART0Buffer[UART0Count] = LPC_UART0->RBR;

UART0Count++;

if ( UART0Count == BUFSIZE )

{

UART0Count = 0; /* buffer overflow */

}

}

else if ( IIRValue == IIR_CTI ) /* Character timeout indicator */

{

/* Character Time-out indicator */

UART0Status |= 0x100; /* Bit 9 as the CTI error */

}

else if ( IIRValue == IIR_THRE ) /* THRE, transmit holding register empty */

{

/* THRE interrupt */

LSRValue = LPC_UART0->LSR; /* Check status in the LSR to see if

valid data in U0THR or not */

if ( LSRValue & LSR_THRE )

{

UART0TxEmpty = 1;

}

else

{

UART0TxEmpty = 0;

}

}

}

/*****************************************************************************

** Function name: UARTInit

**

** Descriptions: Initialize UART port, setup pin select clock, parity, stop bits, FIFO, etc.

**

** parameters: portNum(0 or 1) and UART baudrate

** Returned value: true or false, return false only if the interrupt handler can't be installed to the

** VIC table

**

*****************************************************************************/

uint32_t UARTInit( uint32_t PortNum, uint32_t baudrate )

7 0 | P a g e

{

uint32_t Fdiv;

uint32_t pclkdiv, pclk;

switch(PortNum)

{

case 0:

{

LPC_PINCON->PINSEL0 &= ~0x000000F0;

LPC_PINCON->PINSEL0 |= 0x00000050; /* Enable TxD0 P0.2 and p0.3 */

/* By default, the PCLKSELx value is zero, thus, the PCLK for

all the peripherals is 1/4 of the SystemFrequency. */

/* Bit 6,7 are for UART0 */

pclkdiv = (LPC_SC->PCLKSEL0 >> 6) & 0x03;

switch ( pclkdiv )

{

case 0x00:

default:

pclk = SystemFrequency/4;

break;

case 0x01:

pclk = SystemFrequency;

break;

case 0x02:

pclk = SystemFrequency/2;

break;

case 0x03:

pclk = SystemFrequency/8;

break;

}

LPC_UART0->LCR = 0x83; /* 8 bits, no Parity, 1 Stop bit */

Fdiv = ( pclk / 16 ) / baudrate ; /*baud rate */

LPC_UART0->DLM = Fdiv / 256;

LPC_UART0->DLL = Fdiv % 256;

LPC_UART0->LCR = 0x03; /* DLAB = 0 */

LPC_UART0->FCR = 0x07; /* Enable and reset TX and RX FIFO. */

NVIC_EnableIRQ(UART0_IRQn);

LPC_UART0->IER = IER_RBR | IER_THRE | IER_RLS; /* Enable UART1 interrupt */

return (TRUE);

}

7 1 | P a g e

case 1:

{

#if 0

LPC_PINCON->PINSEL0 &= ~0xC0000000;

LPC_PINCON->PINSEL0 |= 0x40000000; /* Enable TxD1 P0.15 */

LPC_PINCON->PINSEL1 &= ~0x00000003;

LPC_PINCON->PINSEL1 |= 0x00000001; /* Enable RxD1 P0.16 */

#else

LPC_PINCON->PINSEL4 &= ~(3 << 0) ;

LPC_PINCON->PINSEL4 |= (1 << 1); /* Enable TxD1 P2.0 function 10*/

LPC_PINCON->PINSEL4 &= ~(3 << 2);

LPC_PINCON->PINSEL4 |= (1 << 3); /* Enable RxD1 P2.1 function 10*/

#endif

/* By default, the PCLKSELx value is zero, thus, the PCLK for

all the peripherals is 1/4 of the SystemFrequency. */

/* Bit 8,9 are for UART1 */

pclkdiv = (LPC_SC->PCLKSEL0 >> 8) & 0x03;

switch ( pclkdiv )

{

case 0x00:

default:

pclk = SystemFrequency/4;

break;

case 0x01:

pclk = SystemFrequency;

break;

case 0x02:

pclk = SystemFrequency/2;

break;

case 0x03:

pclk = SystemFrequency/8;

break;

}

LPC_UART1->LCR = 0x83; /* 8 bits, no Parity, 1 Stop bit */

Fdiv = ( pclk / 16 ) / baudrate ; /*baud rate */

LPC_UART1->DLM = Fdiv / 256;

LPC_UART1->DLL = Fdiv % 256;

LPC_UART1->LCR = 0x03; /* DLAB = 0 */

LPC_UART1->FCR = 0x07; /* Enable and reset TX and RX FIFO. */

NVIC_EnableIRQ(UART1_IRQn);

LPC_UART1->IER = IER_RBR | IER_THRE | IER_RLS; /* Enable UART1 interrupt */

return (TRUE);

7 2 | P a g e

}

case 2:

break;

case 3:

LPC_SC->PCONP |= (1 << 25);

#if 0

LPC_PINCON->PINSEL0 &= ~0x0000000F;

LPC_PINCON->PINSEL0 |= 0x0000000A; /* RxD3 is P0.1 and TxD3 is P0.0 */

#else

LPC_PINCON->PINSEL9 |= 0x0F000000; /* RxD3 is P4.29 and TxD3 is P4.28 */

#endif

/* By default, the PCLKSELx value is zero, thus, the PCLK for

all the peripherals is 1/4 of the SystemFrequency. */

/* Bit 18~19 is for UART3 */

pclkdiv = (LPC_SC->PCLKSEL1 >> 18) & 0x03;

switch ( pclkdiv )

{

case 0x00:

default:

pclk = SystemFrequency/4;

break;

case 0x01:

pclk = SystemFrequency;

break;

case 0x02:

pclk = SystemFrequency/2;

break;

case 0x03:

pclk = SystemFrequency/8;

break;

}

LPC_UART3->LCR = 0x83; /* 8 bits, no Parity, 1 Stop bit */

Fdiv = ( pclk / 16 ) / baudrate ; /*baud rate */

LPC_UART3->DLM = Fdiv / 256;

LPC_UART3->DLL = Fdiv % 256;

LPC_UART3->LCR = 0x03; /* DLAB = 0 */

LPC_UART3->FCR = 0x07; /* Enable and reset TX and RX FIFO. */

NVIC_EnableIRQ(UART3_IRQn);

LPC_UART3->IER = IER_RBR | IER_THRE | IER_RLS; /* Enable UART3 interrupt */

return (TRUE);

7 3 | P a g e

}

return( FALSE );

}

/*****************************************************************************

** Function name: UARTSend

**

** Descriptions: Send a block of data to the UART 0 port based

** on the data length

**

** parameters: portNum, buffer pointer, and data length

** Returned value: None

**

*****************************************************************************/

void UARTSend( uint32_t portNum, uint8_t *BufferPtr, uint32_t Length )

{

switch(portNum)

{

case 0:

while ( Length != 0 )

{

/* THRE status, contain valid data */

while ( !(UART0TxEmpty & 0x01) );

LPC_UART0->THR = *BufferPtr;

UART0TxEmpty = 0; /* not empty in the THR until it shifts out */

BufferPtr++;

Length--;

}

break;

case 1:

while ( Length != 0 )

{

/* THRE status, contain valid data */

while ( !(UART1TxEmpty & 0x01) );

LPC_UART1->THR = *BufferPtr;

UART1TxEmpty = 0; /* not empty in the THR until it shifts out */

BufferPtr++;

Length--;

}

break;

case 2:

7 4 | P a g e

default:

break;

case 3:

while ( Length != 0 )

{

/* THRE status, contain valid data */

while ( !(UART3TxEmpty & 0x01) );

LPC_UART3->THR = *BufferPtr;

UART3TxEmpty = 0; /* not empty in the THR until it shifts out */

BufferPtr++;

Length--;

}

break;

// return;

}

}

/******************************************************************************

** End Of File

#include "lpc17xx.h"

#include "type.h"

#include "uart.h"

extern volatile uint32_t UART3Count;

extern volatile uint8_t UART3Buffer[BUFSIZE];

extern volatile uint32_t UART1Count;

extern volatile uint8_t UART1Buffer[BUFSIZE];

extern volatile uint32_t UART0Count;

extern volatile uint8_t UART0Buffer[BUFSIZE];

/*****************************************************************************

** Main Function main()

int main (void)

{

SystemInit();

UARTInit(0, 9600);

UARTInit(1, 9600); /* baud rate setting */

UARTInit(3, 9600); /* baud rate setting */

UARTSend( 0, "\r\n MANOJ, KISHORE, POSANI \r\n", sizeof("\r\n MANOJ, KISHORE, POSANI \r\n"));

UARTSend( 1, "\r\nMANOJ, KISHORE, POSANI\r\n", sizeof("\r\nMANOJ, KISHORE, POSANI\r\n"));

7 5 | P a g e

UARTSend( 3, "\r\nMANOJ, KISHORE, POSANI\r\n", sizeof("\r\nMANOJ, KISHORE, POSANI\r\n"));

UARTSend( 0, "Testing UART0\r\n", sizeof("Testing Uart0\r\n"));

UARTSend( 1, "Testing UART1\r\n", sizeof("Testing Uart1\r\n"));

UARTSend( 3, "Testing UART3\r\n", sizeof("Testing Uart3\r\n"));

while (1)

{ /* Loop forever */

if ( UART3Count != 0 )

{

LPC_UART3->IER = IER_THRE | IER_RLS; /* Disable RBR */

UARTSend( 3, (uint8_t *)UART3Buffer, UART3Count );

UART3Count = 0;

LPC_UART3->IER = IER_THRE | IER_RLS | IER_RBR; /* Re-enable RBR */

}

if ( UART1Count != 0 )

{

LPC_UART1->IER = IER_THRE | IER_RLS; /* Disable RBR */

UARTSend( 1, (uint8_t *)UART1Buffer, UART1Count );

UART1Count = 0;

LPC_UART1->IER = IER_THRE | IER_RLS | IER_RBR; /* Re-enable RBR */

}

if ( UART0Count != 0 )

{

LPC_UART0->IER = IER_THRE | IER_RLS; /* Disable RBR */

UARTSend( 0, (uint8_t *)UART0Buffer, UART0Count );

UART0Count = 0;

LPC_UART0->IER = IER_THRE | IER_RLS | IER_RBR; /* Re-enable RBR */

}

}

7 6 | P a g e

14. Conclusions

Despite of few technical complications, the project has been successfully completed. Few

objectives of the desired RT Kernel is at stake viz. multi-tasking. Features of the RT Kernel

implemented supports Portability, Real Time character, Multi-Processing by employing Two

stage scheduler. Interrupt latency is also considered to make the system accurate. Driver

framework of the kernel is so designed to adopt fast evolving data transfer/analysis processed

easier.

As the concepts of designing a stable Real Time Kernel remain to be explored, the work may

not be on par to satisfy time bounded industrial needs.

15. Recommendations for future work

Kernel development provides a lot of scope to solve burning current issues. Automative

thinking is duly implemented basing on practical considerations, servers the evolving trends

in a sophisticated environment. Basing upon the implementation, design of a Real Time

Kernel can be extended to frame configurable kernels for fast prototyping scheduling

algorithms in terms of aperiodic servers, concurrency control protocols. A standard kernel of

compliance is highly appreciable. Sensitive issues like control and security of distributed

embedded systems can be monitored with slight modification to the designed kernel.

Control units of vehicles are taken relying upon the evolving trends of auto-mobile sector.

Graphical LCD has got its own limitations in sense of chromacity and luminence; displaying

graphics would be a tiresome job in order to ease the application we would traverse the path

toward TFT touch screen display. Controllable power systems are to be designed by using

Cortex M3 basing on the practical features of error correction, fault self diagnosis, over

current and over voltage protection.

7 7 | P a g e

16. Refernces

[1] Enrico Perla, ―A guide to kernel exploitation‖, ISBN 978-1-59749-486-1.

[2] Joseph Kong, ―Designing BSD Root kits‖, ISBN 978-1-59327-142-8.

[3] Jorg Helcel, ―Designing Embedded Processor‖, ISBN 978-1-402D-5869-1.

[4] Gene Sally, ―Pro Linux Embedded systems‖ ISBN 978-1-4302-7226-7.

[5] Thesis report on ―Design and implementation of a real time kernel – Volume II by

Soumyadeb Mitra‖.

[6] Understanding the Linux Kernel, 3rd

edition(2005).

[7] Linux kernel module programming guide.

[8] http://www.ni.com/ - EMBEDDED FOR ARM PORTING GUIDE.

[9] people.ece.cornell.edu- design of Graphical LCD Driver

[10] http://www.datasheetarchive.com/cortex%20m3-datasheet.html

[11] http://www.arm.com/products/processors/cortex-m/cortex-m3.php

[12] http://www.alldatasheet.com/datasheet-pdf/pdf/275723/PHILIPS/LPC1768.html

[13] http://en.wikipedia.org/wiki/Real-time_operating_system

[14] http://en.wikipedia.org/wiki/ARM_Cortex-M

[15] www.arm.com/files/pdf/IntroToCortex-M3.pdf

[16] www-micrel.deis.unibo.it/LABARCH/slidecorso2012/ArchiARM2.pdf

7 8 | P a g e

17. Appendix

System File for main.c

#include "lpc17xx.h"

#include "hardware.h"

#include "type.h"

#include "utils.h"

#include "64x128GLCD.h"

extern U8 data_table[];

/**

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

**********

Function Name : is_valid_ascii()

Description :

Input : Void

Output : Void

Note :

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

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

*/

U8 is_valid_ascii(S8 key)

{

U8 retval = FALSE;

if(key >= ' ' && key <= '~')

retval = TRUE;

return retval;

}

/**

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

**********

Function Name : lcd_display_char()

Description :

Input : Void

Output : Void

Note :

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

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

*/

void lcd_display_char(U8 charecter)

{

U8 width = 0, index = 0, data = 0;

width = get_width_of_char(charecter);

for(index = 0; index < width; index++)

{

7 9 | P a g e

data = get_data_from_data_table(charecter, index);

LCD_WRITE_DATA(data);

}

}

/**

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

**********

Function Name : lcd_display_string()

Description :

Input : Void

Output : Void

Note :

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

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

*/

void lcd_display_string(U8 *str)

{

if(str == NULL)

return;

while(*str != (U32)NULL)

{

lcd_display_char(*str);

str++;

}

}

/**

Program code for displaying special characters on to Graphical LCD

--------------------------##########################----------------------------------------------------

#include "type.h"

#include "utils.h"

#include "64x128GLCD.h"

#define MAX_THICKNESS 4

#define NUM_OF_ROWS 64

#define NUM_OF_COL 128

#define NUM_OF_PAGES 8

U8 frame_buf[NUM_OF_COL][NUM_OF_PAGES];

enum BRUSH_TYPE

{

BRUSH_OFF,

BRUSH_ON,

BRUSH_XOR

};

8 0 | P a g e

/**

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

Function Name : lcd_goto_xy()

Description :

Input :

Output : none

Note :

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

*/

void lcd_goto_xy(U8 x_address, U8 y_address)

{

U8 page_num = x_address/NUM_OF_PAGES;

LCD_SET_PAGE(PAGE1 + page_num, y_address);

}

/**

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

Function Name : put_pixel()

Description :

Input :

Output : none

Note :

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

*/

void put_pixel(U16 px, U16 py, U8 brush)

{

U8 data = 0;

U16 page_num = 0;

if((px< NUM_OF_ROWS) && (py < NUM_OF_COL))

{

page_num = px / NUM_OF_PAGES;

data = 1 << (px % 8);

lcd_goto_xy(px,py);

switch(brush)

{

case BRUSH_ON:

frame_buf[py][page_num] |= data;

break;

case BRUSH_OFF:

frame_buf[py][page_num] &= ~data;

break;

8 1 | P a g e

case BRUSH_XOR:

frame_buf[py][page_num] ^= data;

break;

default:

break;

}

LCD_WRITE_DATA(frame_buf[py][page_num]);

}

}

/**

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

Function Name : lcd_draw_line()

Description :

Input :

Output : none

Note :

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

*/

void lcd_draw_line(U16 x1,U16 y1,U16 x2,U16 y2,U16 thickness)

{

S16 dx,dy,dxabs,dyabs,i,px,py,sdx,sdy,x,y;

U16 j = 0;

if(thickness > MAX_THICKNESS)

{

thickness = MAX_THICKNESS;

}

dx = x2 - x1;

dy = y2 - y1;

sdx = SIGN(dx);

sdy = SIGN(dy);

dxabs = ABSOLUTE(dx);

dyabs = ABSOLUTE(dy);

x = 0; y = 0;

px = x1;

py = y1;

if(dxabs >= dyabs)

{

for(i=0;i <=dxabs;i++)

8 2 | P a g e

{

y += dyabs;

if(y >= dxabs)

{

y -= dxabs;

py += sdy;

}

for(j = 0; j < thickness; j++)

{

put_pixel(px+j,py,BRUSH_ON);

}

px +=sdx;

}

}

else

{

for(i=0; i<=dyabs;i++)

{

x += dxabs;

if(x >= dyabs)

{

x -= dyabs;

px += sdx;

}

for(j = 0; j < thickness; j++)

{

put_pixel(px+j,py,BRUSH_ON);

}

py += sdy;

}

}

}

/**

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

Function Name : lcd_draw_circle()

Description :

Input :

Output : none

Note : Bresenham's Circle Algorithm

Taken from http://en.wikipedia.org/wiki/Bresenham's_line_algorithm

*/

void lcd_draw_circle(U16 x0, U16 y0, U16 radius)

{

S32 f = 1 - radius;

8 3 | P a g e

U16 ddF_x = 0;

S32 ddF_y = -2 * radius;

U16 x = 0;

U16 y = radius;

put_pixel(x0, y0 + radius,BRUSH_ON);

put_pixel(x0, y0 - radius,BRUSH_ON);

put_pixel(x0 + radius, y0,BRUSH_ON);

put_pixel(x0 - radius, y0,BRUSH_ON);

while(x < y)

{

if (f >= 0)

{

y--;

ddF_y += 2;

f += ddF_y;

}

x++;

ddF_x += 2;

f += ddF_x + 1;

put_pixel(x0 + x, y0 + y,BRUSH_ON);

put_pixel(x0 - x, y0 + y,BRUSH_ON);

put_pixel(x0 + x, y0 - y,BRUSH_ON);

put_pixel(x0 - x, y0 - y,BRUSH_ON);

put_pixel(x0 + y, y0 + x,BRUSH_ON);

put_pixel(x0 - y, y0 + x,BRUSH_ON);

put_pixel(x0 + y, y0 - x,BRUSH_ON);

put_pixel(x0 - y, y0 - x,BRUSH_ON);

}

}