Page 1
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
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
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
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
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
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
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
• 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
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
Fig.3 ARM Cortex M3 v/s ARM7TDMI
Note: Dhrystone MIPS (DMIPS); Million Instructions Per Second (MIPS)
Page 11
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
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
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
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
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
Fig.4 Pin Out Diagram of LM3S608
Page 17
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
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
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
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
• 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
• 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
• 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
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
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
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
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
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
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
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
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
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)