School this scheduler is implemented in C in the

School of Electrical and Electronic Engineering, Newcastle University

 

 

 

 

 

EEE8068: Wireless Embedded
Systems Coursework Report

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

 

 

 

 

 

 

Student: Chen Minhui

 

1. Abstract

In this experiment, a Time Triggered Cooperative
Scheduler (TTCS) was required to design and this scheduler is to control 8
different LEDs in the ARM board to flash in different periods and with different
specifically phases and the brightness of LED is implemented by the PWM
technique. When a LED in the system meets an overrun occasion, this LED will
stop to do nothing and other LEDs run normally. And this scheduler is
implemented in C in the UNIX environment. For this experiment, I have finished
the task that makes all LEDs stop to do nothing while pressing the button, but
for the rest part which makes the rest LEDs work normally except for the
overrun LED, I have not finish yet. The practice of designing a scheduler to
control 8 tasks can promote the understanding of scheduling concepts and learn
how to design a TTCS scheduler.

2. Introduction

2.1 Task specification

According to the handout,
a Time Triggered Cooperative Scheduler (TTCS) was asked to implement in C and this
TTCS scheduler is to control 8 different LEDs on an ARM board to
flash with different periods. Specifically, these LEDs are implemented by eight
short periodic tasks, and four of them are required to flash in every tick interval,
while two tasks are required to flash in every odd tick interval and two tasks
are required to flash in every even tick interval. When the overrun is happening,
the running task which is followed by the normal sequence of task execution should
be interrupted by the timer. The tasks in the line after the overrunning task
may not be started under the overrun conditions, but the relevant data (e.g. the
flashing period and the phase of LED flashing) must be right.

2.2 Scheduler

The scheduler refers to using the scheduling
algorithm to schedule the tasks in a specific sequence. There are many parts
inside a scheduler (e.g., interrupts, timer, one or several processors, task
queue, CPU modes, task model, scheduler model, protection from overruns, etc.).
And for this experiment, this scheduler should be a Time Triggered Cooperative
Scheduler (TTCS) as required in the task specification. As this scheduler is
cooperative, therefore when one task is running, the next task should wait
rather than pre-empt the running task. 1

2.3 Toolchain

In this task, the X-server Xming software and
Cygwin are required to use, as the programming environment is based on the UNIX
command-line shell. After the two software running, rxvt-x can be started. In the
command window of rxvt-x, it is required to create design directory by typing
mkdir eee8068cwrk in the command window and then change current directory to
the design directory by typing cd eee8068cwrk. After these steps, it is required
to copy the standard design files: Makefile, armfpga.ld, ex.h, howto.txt, and
startup.s files into the design directory. When the coding of scheduler is
finished, the debugger kmd should be copied on to the drive D:, as it will not
run from drive H:, and then the code can be tested to flash the LED with
different periods in the board.

2.4 Hardware Platform

The platform is based on an ARM-XLINIX board
(SAM9261), which is a complete system-on-chip built around the processor with
an extended DSP instruction set and Java accelerator. The SAM9261 is an optimized
host processor for applications with an LCD display. The 160 Kbyte integrated
SRAM can be configured as a frame buffer to minimise the impact for LCD refresh
on the overall processor performance and the External Bus Interface
incorporates controllers for synchronous DRAM (SDRAM) and Static memories and
features specific interface circuitry for Compact Flash and NAND Flash. (Atmel | SMART SAM9261 Datasheet, n.d.)2 The board
internal structure shown below:

Figure 1: SAM9261 Board Internal Structure

3. Implementation

3.1 Scheduler Basic Structure

For
this TTCS scheduler, according to the requirement, there should be 6 tasks
executed in each tick. For each timeline TTS task, its task model can be shown
in figure 2. The task queue is updated on each tick and their code is stored in
ROM. As there are 8 tasks in the specification and thus 6 tasks should be
executed in each tick, so its timeline TTS state graph can be described as in
figure 3

Figure 2: Timeline TTS Task Model

 

Figure 3: Timeline TTS Task State Graph

3.2 Naked Functions

All
functions in the scheduler are implemented as ‘naked functions’, because it has
no prologue or epilogue and stack needs to be reinitialised at the beginning. 3
By observing the figure 3, 6 naked functions mainly should be built and they
are respectively main(), irq(), dispatcher(), task(), swi(), and sleep_state().
Each naked function executes a specific work.    

Main() – Initialization

       Irq() – Update

       Dispatcher() – Dispatcher

       Task() – Tasks (User Mode)

       swi() – Hardware drivers

       sleep_state() – Sleep

3.3 Interrupts

There
are two types of interrupt used in the system and they are respectively
hardware interrupt and software interrupt. The hardware interrupt is raised
from a clocked source outside the system every 1 millisecond. The function
called irq() is used to reset the variable “tog” which is used to decide which
6 tasks should be executed in every tick as in each tick, only 6 LEDs can be executed.
The only way to switch different modes (e.g. supervisor mode and user mode) is
to use the software interruption instruction.

3.4 Scheduler development

Based
on the basic structure of the scheduler, some development need to be added to
achieve the task specification and make the code can be compiled.

3.4.1 Main
Function & Sleep Function

For the main function, it aims to
initialise the timer after the previous interrupt finished. The IRQ function is
triggered by a condition when “*TIMER_COMPARE_P” has the same value as “*TIMER_P”.  And sleep function will be executed until the
timer raises first interrupt.    

       

3.4.2 Interrupt
Function

Inside the irq function, “irq” signal should be reset and the “*TIMER_COMPARE_P”
should be programmed to the next interrupt. As the CPU mode is changed, from
IRQ to SVC, then interrupts become disabled, and “IRQ_ENABLE” should be needed
again. In the following step, a variable tog is set to execute which 6 tasks
and for this 6 tasks, the tasks 0,1,2,3 should be always executed in each tick.
If tog meet the occasion (‘tog=0’), the task 4 and 5 (LED 4 and 5) should be
executed. If tog meet the occasion (‘tog=1’), the task 6 and 7 (LED 6 and 7)
should be executed.

3.4.3 Dispatcher
Function

The
main function of the dispatcher function is to reset the task queue. There is a
global variable “q_index” to represent which task should be executed, starting
from task 0. After arranging the task queue, task function can be executed.
Equally as before, when switching from “SVC_MODE” to “USR_MODE”, “IRQ_ENABLE”
should be executed. A struct can be defined in the starting part to simplify
the code and to make the flash period and other relevant parameters of
different LEDs corresponds to specific tasks (e.g. {0,0,500,20,0,0,1000} for
task 0). The struct is shown below.

3.4.4 Task
Function

The
task function mainly contains 3 parts: the sawtooth function, the brightness
function and the pwm_counter function. The sawtooth function. The sawtooth
function is shown as below. For the sawtooth function, it aims to make the
variable (dataa.b_cnt) add “1” continuously until the variable
(dataa.b_cnt) satisfies the “if” statement. When it meets the condition of “if”
statement, the variable (dataa.b_cnt) will be 0.

The
second part is brightness function as shown below. The value of the parameter
(dataa.brightness) can be divided into two parts by using an “if” statement
to choose between rising and falling part. This is because that for a flashing
condition, it contains a stage to rise to maximum brightness and another stage
from maximum brightness to darkness.

The
third part is to light the LEDs by using Pulse Width Modulation (PWM) and the
period of PWM are required to be set as 20ms (dataa.modulus). A variable
(pwm_counter) is defined which add “1” continuously when the variable is less
than 20 and when it is equal to 20, it will be 0. As the brightness of LED is
controlled by PWM, hence the occasion when the LED has maximum brightness(dataa.half_bcnt_mod)
should happen simultaneously with the stage that the variable (pwm_counter)
should be the value of “dataa.modulus”. According to the analysis above, a
relationship between the four parameters can be built shown below:

 

Then,
a problem here should be solved that the task function executes a task every
time, which means only one LED can work, but 6 LEDs are asked to work
simultaneously. Thus, by programming as “led_temp |= 1