Top Banner
Project Report on Application using uC/OS-II on Stellaris® Guru Evaluation Kit for Teaching ARM® Cortex™- M3 and Embedded SystemsBy VAISHNAV JAYKUMAR P. (E.C.-121) & THAKKAR SUKET J. (E.C.-116) Under Supervision of Prof. P.V.Patel Department of Electronics & Communication, Faculty of Technology, Nadiad. Oct,2012
32

Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Oct 30, 2014

Download

Documents

Suket

Project Report on

“ Application using uC/OS-II on Stellaris® Guru Evaluation Kit for Teaching ARM® Cortex™- M3 and Embedded Systems”
By

VAISHNAV JAYKUMAR P. (E.C.-121) & THAKKAR SUKET J. (E.C.-116)
Under Supervision of

Prof. P.V.Patel

Department of Electronics & Communication, Faculty of Technology, Nadiad. Oct,2012

CERTIFICATE

This is to certify that the project titled “Application using uC/OS-II on Stellaris®

Guru Evaluation Kit for Teaching ARM® Cortex™- M3 and Embedded Systems” by VA
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Project Report on

“ Application using uC/OS-II on Stellaris® Guru Evaluation Kit for

Teaching ARM® Cortex™- M3 and Embedded Systems”

By

VAISHNAV JAYKUMAR P. (E.C.-121)

&

THAKKAR SUKET J. (E.C.-116)

Under Supervision of

Prof. P.V.Patel

Department of Electronics & Communication,

Faculty of Technology, Nadiad.

Oct,2012

Page 2: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

CERTIFICATE

This is to certify that the project titled “Application using uC/OS-II on Stellaris®

Guru Evaluation Kit for Teaching ARM® Cortex™- M3 and Embedded

Systems” by VAISHNAV JAYKUMAR P. & THAKKAR SUKET J. is a

bonafide work carried out by him under my guidance and supervision.

Prof. P.V. Patel Dr. N.J.Kothari

Project Supervisor, Head,

Department of Electronics & Department of Electronics &

Communication Communication

DDU , Nadiad. DDU , Nadiad.

Page 3: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

ABSTRACT

The goal of the project is to understand the features of Stellaris Guru Evaluation Kit and to

port a Real Time Operationg System (RTOS) on it to do & understand multitasking.

Three tasks are created and multitasking has been done to bring out the advantage of the

RTOS , that is aading more intelligence and time accurate system.

We are thankful to our project supervisor and head of department for including term project

in 7th

semester. It is very helpful in improving our fundamentals and also getting in touch

with the new technology trends. Term project got very useful while dealing with company

interviews.

We are very thankful to Prof. M.J. Limachia sir who aspired to make project on this kit. We

are also thankful to Prof. V.A.Vohra sir who has provided the guidance to fulfil the project on

RTOS.

Vaishnav Jaykumar P.(EC-121)

Thakkar Suket J.(EC-116)

Page 4: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

APPLICATIONS OF PROJECT

The project is used to do efficient multitasking between several tasks (i.e. LED patterns ,

temperature control , MIC ,UART etc. for this kit).

Soft real time operations can be done successfully, which in turn get useful getting

knowledge about hard real time systems (i.e. PLC).

Since it‟s real time system it can be used in Vehicle Braking , Toaster.

Page 5: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

CONTENTS

No. Name of topic Page No.

1. The Stellaris Guru kit 1

2. Overview of ARM Cortex M3

3. Evolution of the ARM Instruction Set

4. LM3S608 Microcontroller Features

5. Components of kit

6. Real Time System & Concepts

7. Working of Semaphore

8. Simulation in Keiluvision4 & Output

9. Troubleshooting

10. References

Page 6: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

LIST OF FIGURES

No. Caption of figures Page No.

1. Stellaris Guru Kit Xyz

2. Kit components

3. ARM Cortex M3 v/s ARM7TDMI

4. Pin Out Diagram of LM3S608

5. Power supply

6. Temperature Sensor and Potentiometer

7. Task operations

8. Task State Diagram

9. Non-Preemptive Kernel

10. Preemptive Kernel

11. Synchronizing tasks and ISRs

12. Tasks synchronizing their activities

13. Screenshots

Page 7: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

1. The Stellaris Guru kit

1.1 Kit Contents

The kit box contains the following items:

1. Stellaris Guru Kit

2. USB Cable

1.2 The Stellaris Guru Kit

Fig.1 Stellaris Guru Kit

1.3 What to Expect?

When you connect the Stellaris Guru kit using the USB cable to your computer a

few indicator LEDs turn on/flash indicating the board is in a ready to use state.

Refer to the annotated Stellaris Guru Fig.4(Pin Out- LM3S608) for locating the indicator

LEDs.

1. LEDs LD3 and LD4 would light flash momentarily for a second confirming ability

to establish serial connection with the computer.

2. The power indicator LED LD1 would be continuously on confirming the board is able to

draw power from the USB.

1.4 Features Overview

• Based on LM3S608 microcontroller family from the TI Stellaris 600 series family.

• User programmable push buttons and ultra[bright LEDs, both unicolor and RGB.

Page 8: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

• Reset pushbutton and power indicator LED.

• A LM35 temperature sensor for taking temperature readings using the Analog to

Digital Convertor.

• Thumbwheel potentiometer for reading analog voltage through one of the ADC

channels of the microcontroller.

• Microphone amplifier with high gain and sensitivity connected to an independent

ADC channel of the microcontroller.

• Ambient light sensor using a LED operated in reverse bias.

• Standard ARM 20[pin JTAG debug connector.

• Arduino compatible interface connector.

• UART0 accessible through a USB virtual COM port (VCP).

• Programmable through UART using preinstalled boot loader.

• USB interface for all communication and power.

Fig.2 Kit components

Page 9: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

2. Overview of ARM Cortex M3

2.1 Features

• 32 bit microprocessor.

• 32 bit data path, 32 bit register bank and 32 bit memory interfaces.

• Harvard Architecture – separate instruction bus and data bus.

• 3 stage pipeline with branch speculation.

• Thumb 2 instruction set.

• No switching between ARM state and thumb state.

• Instruction fetches are 32 bits. Up to two instructions can be fetched in one cycle.

As a result, there‟s more available bandwidth for data transfer.

• ALU with hardware divide and single cycle multiply.

• Configurable Nested Vector Interrupt Controller (NVIC).

• Maximum of 240 external interrupts can be configured.

• Low gate count, suitable for low power designs.

• Memory Protection Unit (MPU).

• Operation Mode Selection – user and privilege modes.

• Advanced debug components.

2.2 Benefits (ARM Cortex M3 v/s ARM7TDMI )

Capabilities beyond ARM7TDMI for the MCU market

No Assembly Required!

Cortex-M3 requires approximately half the Flash-memory

of ARM7 implementations

2-4 times faster on MCU control applications.

• Raw interrupt performance: 85% faster

• PID (process control) main loop: 217% faster

• Multiply-intensive code: 294% faster

• Divide-intensive code: 726% faster

Page 10: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Fig.3 ARM Cortex M3 v/s ARM7TDMI

Note: Dhrystone MIPS (DMIPS); Million Instructions Per Second (MIPS)

Page 11: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

3. Evolution of the ARM Instruction Set

Enhancement and extension of instruction sets used by the ARM processors has been

one of the key driving forces of the architecture‟s evolution.

Historically, two different instruction sets were supported on the ARM processor: the

ARM instructions, which are 32 bits and Thumb instructions, which are 16 bits.

During program execution, the processor can be dynamically switched between the ARM

state andt he Thumb state. The Thumb instruction set provides only a subset of the ARM

instructions, but it can provide higher code density. It is useful for products with tight

memory requirements.

The Thumb-2 technology extended the Thumb Instruction Set Architecture (ISA) into a

highly efficient and powerful instruction set that delivers significant benefits in terms

of ease of use, code size and performance.

The extended instruction set in Thumb-2 is a superset of the previous 16-bit Thumb

instruction set, with additional 16-bit instructions alongside 32-bit instructions. It allows

more complex operations to be carried out in the Thumb state, thus allowing higher

efficiency by reducing the number of states switching between ARM state and Thumb

state.

The Cortex-M3 processor supports only the Thumb-2 (and traditional Thumb)

instruction set. Instead of using ARM instructions, as in traditional ARM processors, it uses

Thumb-2 instruction set for all operations. As a result, the Cortex-M3 processor is

not backward compatible with traditional ARM processors, which use the ARM as

well as Thumb instruction set.

The Thumb-2 instruction set is a very important feature of the ARMv7 architecture. For the

first time, hardware divide instruction is available on an ARM processor, and a number of

multiply instructions are also available.

Original 16 bit THUMB Instruction Set

Subset of ARM Instructions

Performs similar function as ARM instructions but in 16-bit code size.

For ARM Instructions

More 16-bit Thmb instructions are required to execute same functions compared to

ARM instructions.

But performance may be degraded.

Hence Introduction of Thumb-2 Instruction Set

Page 12: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Enhancement of 16-bit Thumb instructions with additional 32-bit instructions

THUMB-2 Instruction Set

• Instruction Set: Thumb2

• Word length: 32 bit

• Architecture: Harvard (ARMv7-M)

• Registers: 13 general purpose, 1 Stack Pointer,

1 Link Register, 1 Program Counter,

1 Program Status, Special Registers

• Benchmark: 1.25 DMIPS/MHz (Dhrystone MIPS)

• Interrupt-Latency: 12 Cycles

• Energy consumption: 0.19 mW/MHz

• Area 5]: 0.86mm2 (Core and Peripherals)

• Note: Does not include optional system peripherals

(MPU & ETM) or integration level component

• Features: NVIC, Sleep modes, MPU,

Bit-Banding, Debug functionality

Page 13: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

4.LM3S608 Microcontroller Features

• 32 bit RISC Performance

32 bit ARM® Cortex™ M3 v7 M architecture.

SysTick timer, providing a simple 24 bit clear on write, decrementing, wrap on zero

counter.

Thumb® compatible Thumb 2 only instruction set.

50 MHz Operation

Integrated Nested Vector Interrupt Controller.

23 interrupt with eight priority levels.

• Internal Memory

32KB single cycle flash.

8KB single cycle SRAM.

• GPIOs

5 28 GPIOs, depending on configuration.

5V tolerant input configuration.

Fast toggle capable of a change every two clock cycle.

Programmable control for GPIO interrupts.

Programmable control for GPIO pad configuration.

• General Purpose Timers

Three general purpose timers modules each of which provides two 16 bit

timers/counters. Each can be conFigured independently:

As a single 32 bit timer.

As one 32 bit Real time Clock.

For Pulse Width Modulation.

• ARM FiRM compliant Watchdog Timer.

• ADC

Eight analog input channels.

Single ended and differential input configurations.

Page 14: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

On chip internal temperature sensor.

Sample rate of 500 thousand samples/second.

• UART

Two fully programmable 16C550 type UARTs.

Separate 16x8 transmit (TX) and receive (RX) FIFOs to reduce CPU interrupt

service loading.

Fully programmable serial interface characteristics 5,6,7 or 8 data bits.

Even/Odd/Stick or No Parity generation.

1 or 2 stop bit generation.

• Synchronous Serial Interface

Master of Slave Operation.

Programmable clock bit rate and operation.

Programmable data frame size from 4 to 16 bits.

• I2C

Devices on the I2C bus can be designated as either master or a slave.

Four I2C modes:

Master transmit

Mater receive

Salve transmit

Slave receive

Two transmission speeds, standard (100kbps) and Fast (400kbps).

Master and slave interrupt generation.

• Analog Comparators

One integrated analog comparator.

Configurable for output to drive an output pin, generate an interrupt or initiate an

ADC sample sequence.

• Power

On chip Low Drop (LDO) voltage regulator with programmable output user

adjustable from 2.25V to 2.75V.

Page 15: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Low power options on controller: Sleep and Deep Sleep Modes.

Low power options for peripherals: software controls shutdown of individual

peripherals.

3.3V supply brownout detection and reporting via interrupt or reset.

• Flexible Reset Sources

Power on Reset (POR)

Reset pin assertion.

Brownout (BOR) detector alerts to system power drops.

Software reset.

Watchdog timer reset.

• JTAG

IEEE 1149.1 1990 compatible Test Access Port (TAP) controller.

Four bits Instruction Register (IR) chain for storing JTAG instructions.

IEEE standard instructions: BYPASS, IDCODE, SAMPLE/PRELOAD, EXTEST

and INTEST.

Integrated ARM Serial Wire Debug (SWD).

The soul of the Stellaris Guru is the LM3S608 microcontroller. It follows the ARM

Cortex-M 32-bit RISC architecture. The LM3S608 used on the kit is in the 48-pin

Thin Quad FlatPackage (TQFP). The pin assignment is shown is Figure 4.

Page 16: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Fig.4 Pin Out Diagram of LM3S608

Page 17: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

5.Components of kit

5.1 Power Supply

The power supply section of the kit is shown below in Figure 5. Power is drawn

directly from the USB bus of a computer, which is at +5V potential. This voltage is then fed

to a Low Drop Out voltage regulator LM1117[3.3 (IC3) to generate +3.3V required by the

microcontroller and other kit components.

Tantalum capacitors C1 and C2 provide input and output filtering respectively. LED1

connected in series with the resistor R1 provides visual indication for power being

supplied to the kit.

Fig. 5 Power supply

5.2 USB Virtual COM Port

The Stellaris Guru kit uses a FT232RL (IC4) USB[to[Serial bridge connected

between UART0 of the microcontroller and the USB. This helps in field

programming of the microcontroller over UART using the supplied boot loader. The

port can also be used to send UART values to a PC application, viz. Hyper Terminal,

Bray++, etc.

5.3 Temperature Sensor and Thumbwheel Potentiometer

To evaluate the analog to digital conversion capabilities of the microcontroller, a LM35

temperature sensor(IC6) and a thumbwheel potentiometer(POT1) are provided on

the board. The two are connected to the same analog channel, ADC7 of the

microcontroller.

Either can be selected by using jumper J2. The LM35 is powered by +5V coming from

the USB bus.

Page 18: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Fig. 6 Temperature Sensor and Potentiometer

5.4 I/O Peripherals – Switches and LEDs

The kit consists of three unicolor LEDs: LD5, LD6 and LD7, one RGB LED: RGB1 and two

user pushbutton: S2 and S3. S2 and S3 are connected to PE0 and PE1 respectively.

The cathodes of LEDs are connected to pins PC5, PC6 and PC7 of the micro controller.

Choice can be made between the three unicolor LEDs and the RGB LED by placing the

appropriate jumper on J1. The anodes of all LEDs are connected to +3.3V. The LEDs are

connected to the Capture/Compare/PWM (CCP) and hence can be used with Pulse Width

Modulation for intensity control.

Page 19: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

6. Real Time System & Concepts

Real-time systems are characterized by the fact that severe consequences will result if logical

as well as timing correctness properties of the system are not met.

Definition:

Real Time Systems are characterized by consequences that result if logical as well as

timing correctness properties of the system are not met

A real-time deadline must be met, regardless of system load

There are two types of real-time systems: SOFT and HARD.

Types of RTOS:

• Soft Real Time

– Tasks are performed by the systems as fast as possible, but failing to complete

within specified deadlines is not catastrophic.

– Video Surveillance, Radio Transmissions, Online Ticket reservation systems, etc..,

• Hard Real Time

– Tasks have to be performed not only correctly but in time. Failure to comply to the

set deadlines would result catastrophical

– Nucleur Reactors, Vehicle Braking, etc...

Most real-time systems have a combination of SOFT and HARD requirements. Real-time

applications cover a wide range. Most applications for real-time systems are embedded. This

means that the computer is built into a system and is not seen by the user as being a

computer.

Examples of embedded systems:

Process control:

Food processing

Chemical plants

Automotive:

Engine controls

Anti-lock braking systems

Office automation:

FAX machines

Copiers

Computer peripherals:

Printers

Terminals

Scanners

Modems

Robots

Aerospace:

Flight management systems

Weapons systems

Page 20: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Jet engine controls

Domestic:

Microwave ovens

Dishwashers

Washing machines

Thermostats

Task Level Response:

• The time taken between the making a process ready to its execution is the Task Level

Response

• Critical operations have to be performed by ISR‟s to ensure that they are dealt in a timely

fashion

• Information for a BG module made available by an ISR is not processed until the

background routine gets its turn to execute

• The worst case task level response time depends on how long the BG loop takes to

Execute.

Resource & Shared Resource:

• A resource is a entity used by the task.

• A resource can be a I/O device, or a variable, a structure or an array.

• A shared resource is a resource that can be used by more than one task. •

• Each task should gain exclusive access to the shared resource to prevent data corruption.

Critical Section of Code:

• Also called as Critical region.

• Should be treated indivisibly.

• Must not be Interrupted.

• To ensure this, interrupts are typically disabled before the critical code is executed &

enabled when the critical code is executed.

Multitasking:

• Multitasking is the process of scheduling and switching the CPU between several tasks.

• A single CPU switches attention between several sequential tasks.

• Multitasking is like FG/BG with multiple BGs.

Advantages of Multitasking:

• Maximizes the CPU Utilization.

• It Provides Modular construction of Applications.

• Application programs are typically easier to design & maintain if Multitasking is used.

Task:

• A task, also called a thread, is a simple program that thinks it has the CPU all to itself.

Page 21: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

• Real Time application involves splitting the work to be done in Tasks.

• Each Task is assigned its own set of CPU Registers, Stack Area and a Priority.

Fig.7: Task operations

Task State:

• DORMANT

• READY

• RUNNING

• WAITING

• ISR

Note: Typically Tasks are infinite loops

Dormant State:

• Corresponds to the task that resides in the memory but has not been made available to

the multitasking Kernel

Ready State:

• A task is READY when it can execute but its priority is less than the currently running task.

Running Task:

• A task is running when it has control of the CPU

Waiting State:

Page 22: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

• A Task is waiting when it requires a occurrence of a event (waiting for an I/O operation to

complete, a shared resource to be available, a timing pulse to occur, time to

expire etc).

ISR State:

• A task is in the ISR State when an interrupt has occurred and the CPU is in the process of

servicing the Interrupt

Figure:8 Task State Diagram

Kernel:

• Fundamental Service provided by the Kernel is Task Switching

• Kernel simplifies the design of a system allowing the application to be divided into several

tasks.

• Kernel adds overhead to the System(ROM & RAM) & also consumes CPU time(2-5%)

Context Switch (Task Switch):

• Save current CPU task‟s context (CPU Registers) on the current task‟s context storage area

• The new task context is restored & start executing the new task

• More the registers higher the overhead

Task Priority:

• A priority is assigned to each task

• The more important the task the more the priority

• Two types of priority assigning

– Static (Assigned at Compile Time)

– Dynamic (Assigned at Execution Time)

Scheduler:

Page 23: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

• Part of the Kernel which will decide the next task to run

• Most RT Kernels are priority based

• Control is always given to highest priority task ready to run

• Two types of priority based Kernels

– Non-Preemptive

– Preemptive

Fig.9 : Non-Preemptive Kernel

Fig. 10: Preemptive Kernel

Semaphores:

• Control Access to a shared resource (ME)

• Signal Occurrence of an event

• Allow two tasks to synchronize their activities

•Synchronization

Further elaboration is done in the section „Working of Semaphore‟.

Page 24: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

7. Working of Semaphore

A task can be synchronized with an ISR, or another task when no data is being

exchanged, by using a semaphore as shown in Figure below . Note that, in this case, the

semaphore is drawn as a flag, to indicate that it is used to signal the occurrence of an event

(rather than to ensure mutual exclusion, in which case it would be drawn as a key). When

used as a synchronization mechanism, the semaphore is initialized to 0. Using a semaphore

for this type of synchronization is using what is called a unilateral rendezvous. A task

initiates an I/O operation and then waits for the semaphore.

When the I/O operation is complete, an ISR (or another task) signals the semaphore and the

task is resumed.

Fig.11 : Synchronizing tasks and ISRs

If the kernel supports counting semaphores, the semaphore would accumulate events that

have not yet been processed. Note that more than one task can be waiting for the event to

occur. In this case, the kernel could signal the occurrence of the event either to:

a) the highest priority task waiting for the event to occur, or

b) the first task waiting for the event.

Depending on the application, more than one ISR or task could signal the occurrence of the

event.

Two tasks can synchronize their activities by using two semaphores, as shown in

Figure below. This is called a bilateral rendezvous. A bilateral rendezvous is similar to a

unilateral rendezvous except both tasks must synchronize with one another before

proceeding.

Fig.12 : Tasks synchronizing their activities.

μC/OS-II Semaphore functions Provides for using same semaphore functions as an

event signaling flag or mutex or counting semaphore

Page 25: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Semaphore for event flag functions

When a semaphore created is used as a an event signaling flag or as counting

semaphore, semaphore value at start = 0, which means event yet to occur and 1 will mean

event occurred.

Semaphore as mutex functions

When a semaphore created is used as a resource acquiring key, Semaphore value at

start = 1, which means resource available and 0 will mean not available.

OSSemCreate (semVal)

OS_Event OSSemCreate (unsigned

short semVal)

To create and initialize semaphores. For

event-flag, key and count, respectively.

OSSemPend (*eventPointer, timeOut,

*SemErrPointer)

void OSSemPend

(OS_Event *eventPointer, unsigned short

timeOut, unsigned byte *SemErrPointer)

To check whether semaphore is pending or

not pending (0 or >0). If pending (=0), then

suspend the task till >0 (released). If >0,

decrement the value of semaphore and run

the waiting codes

OSSemAccept (*eventPointer)

• unsigned short OSSemAccept

(OS_EVENT *eventPointer)

To check whether semaphore value > 0 and

if yes, then retrieve and decrement. Used

when there is no need to suspend a task,

only decrease it to 0 if value is not already

zero.

OSSemPost (*eventPointer)

unsigned byte OSSemPost

(OS_EVENT*eventPointer)

SemVal if 0 or more, increment.

Increment makes the semaphore again not

pending for the waiting tasks.

Page 26: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

8. Simulation in Keiluvision4 & Output

Fig.13.1: This shows how to allocate priorities to tasks in main.h file.

Fig.13.2: This figure shows how to define Task function.

Page 27: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Fig.13.3: In this figure we have to create our application tasks which are specified

here as Task(A,B & C).

Fig.13.4: As priority of Task C is higher it will execute first.

Page 28: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Fig.13.5: As Task A has got 2nd priority so after execution of Task C, due to

OSdelay(), it will jump here.

Fig.13.6: As Task b has got 3rd priority, due to sempost , so that it will jump here.

Page 29: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Fig.13.7: This figure shows how to give delay in OS. As in above figure 6u is defined, which

means 6 microsec delay. We can change value over there according to our application.

Fig.13.8: This figure shows after execution of Task C two step, see in GPIO C window I/O

Port pin 7 goes low.

Page 30: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

Fig.13.9: This figure shows after execution of Task A all step, see in GPIO B window I/O

Port pin (7,6,5) goes low.

Fig.13.10: This figure shows after execution of Task B, as shown in GPIO D I/O pin (7,5)

gows down, in figure blue arrow indicates that, due to time over of OSdelay it will again go

to Task C, now when again OSdelay comes in TaskC it will resume its position from where it

had ended, in figure it is shown by yellow color arrow.

Page 31: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

9. Troubleshooting

Since the software and hardware both were new for us , it took much time first to become

familiar with it.

Our half of the semester(!) just gone understanding Eclipse,Cortex-M3.

It was tedious doing all time the configuration settings for each new project created. That‟s

what shown in Manual of kit.

After becoming familiar we are given a task to port OS in kit & perform an application on it

afterwards. That‟s now new challenge. We wandered on internet & to our CE friends to know

concepts of OS & then for knowing the concepts of Semaphore. VAV sir helped a lot.

We got tons of errors(!) while simulating the program in Eclipse.

Then the tragedy was eliminated , when Keil comes to help us saying that I‟m with you why

Eclipse? . Keil uv4 was helpful running our 8KB code , which is not possible in Keil uv3

(2KB max. size).

Atlast the OS got ported in kit(bingo). Now, 75% task is done. But 25% was also not easy.

We gone through Rajkamal book for embedded and also uCOS-II ebook. Many fundamentals

got cleared. Then the tasks created and multitasking is done.

Also , making an report is also not an easy task !...

Page 32: Application using RTOS_ARM Cortex M3_Project Report_VII Sem

10. References

1. Stellaris Guru Manual V7 Final ebook.

2. uCOSII_ebook

3. Use r Guide for „Stellaris® Peripheral Driver Library;.

4. Embedded System by RajKamal.

5. www.dreamcatcher.asia/cw (ARM Cortex M3 , Thumb State)

6. www.pudn.com (OS Porting information)

7. www.en.wikipedia.com/RTOS (Information about Real Time Systems)