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 VAISHNAV JAYKUMAR P. & THAKKAR SUKET J. is a
bonafide work carried out by him under my guidance and supervision.

Prof. P.V. Patel Project Supervisor, Department of Electronics & Communication DDU , Nadiad.

Dr. N.J.Kothari Head, Department of Electronics & Communication DDU , Nadiad.

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)

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 its real time system it can be used in Vehicle Braking , Toaster.

CONTENTS

No.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Name of topic
The Stellaris Guru kit Overview of ARM Cortex M3 Evolution of the ARM Instruction Set LM3S608 Microcontroller Features Components of kit Real Time System & Concepts Working of Semaphore Simulation in Keiluvision4 & Output Troubleshooting References

Page No.
1

LIST OF FIGURES

No.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Caption of figures
Stellaris Guru Kit Kit components ARM Cortex M3 v/s ARM7TDMI Pin Out Diagram of LM3S608 Power supply Temperature Sensor and Potentiometer Task operations Task State Diagram Non-Preemptive Kernel Preemptive Kernel Synchronizing tasks and ISRs Tasks synchronizing their activities Screenshots

Page No.
Xyz

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.

 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

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, theres 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: PID (process control) main loop: Multiply-intensive code: Divide-intensive code: 85% faster 217% faster 294% faster 726% faster

Fig.3 ARM Cortex M3 v/s ARM7TDMI Note: Dhrystone MIPS (DMIPS); Million Instructions Per Second (MIPS)

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 architectures 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

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

THUMB-2 Instruction Set Instruction Set: Word length: Architecture: Registers: Thumb2 32 bit Harvard (ARMv7-M) 13 general purpose, 1 Stack Pointer, 1 Link Register, 1 Program Counter, 1 Program Status, Special Registers 1.25 DMIPS/MHz (Dhrystone MIPS) 12 Cycles

Benchmark: Interrupt-Latency:

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

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.

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.

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.

Fig.4 Pin Out Diagram of LM3S608

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.

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.

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

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 ISRs 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.

 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:

 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 tasks context (CPU Registers) on the current tasks 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:

 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.

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

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) OSSemPend (*eventPointer, timeOut, *SemErrPointer) void OSSemPend (OS_Event *eventPointer, unsigned short timeOut, unsigned byte *SemErrPointer) OSSemAccept (*eventPointer) unsigned short OSSemAccept (OS_EVENT *eventPointer) To create and initialize semaphores. For event-flag, key and count, respectively. 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 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. SemVal if 0 or more, increment. Increment makes the semaphore again not pending for the waiting tasks.

OSSemPost (*eventPointer) unsigned byte OSSemPost (OS_EVENT*eventPointer)

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.

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.

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.

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.

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.

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. Thats 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. Thats 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 Im 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 !...

10. References
1. 2. 3. 4. 5. 6. 7. Stellaris Guru Manual V7 Final ebook. uCOSII_ebook Use r Guide for Stellaris Peripheral Driver Library;. Embedded System by RajKamal. www.dreamcatcher.asia/cw (ARM Cortex M3 , Thumb State) www.pudn.com (OS Porting information) www.en.wikipedia.com/RTOS (Information about Real Time Systems)