Porting UCOS to the Am29200 Microcontroller by Becky Cavanaugh - Sept. 17, 1993 Introduction UCOS ("Micro-COS") is a portable, preemptive, real-time,

fiercebunElectronics - Devices

Nov 2, 2013 (3 years and 9 months ago)

98 views

Porting UCOS to the Am29200 Microcontroller

by Becky Cavanaugh
-

Sept. 17, 1993




Introduction



UCOS ("Micro
-
COS") is a portable, preemptive, real
-
time,
multitasking kernel. UCOS stands for Micro
-
Controller Operating System.
Originally written for the
Motorola MC68HC11 microcontroller, UCOS was
modified to remove the target
-
specific limitations and make it portable
for use with other processors. Porting UCOS to the Am29200
microcontroller operating environment required rewriting the processor
-
specific
portions of the code. These include TCB (Task Control Block)
initialization for each task, synchronous task switching, asynchronous
task switching, timer initialization, trap vector initialization, and a
timer interrupt routine.



Section 1

describes the
Am29200
-
specific portions of UCOS.



Section 2

describes how to initialize UCOS and start the multi
-
tasking process.



Section 3

lists the UCOS files and their contents.


Section 1


Specifics of the Am29200 Implementation of UCOS




TCB Initializat
ion



The TCB is used by UCOS to maintain the state of a task when it is
preempted. For this implementation, each task is allocated its own
register and memory stack. Daniel Mann's book, Programming the 29K RISC
Family, provides the TCB layout (see Figur
e 1) and the register usage
convention. The latter was necessary in order to conform to OS
-
boot in
the debug phase. Please note that the register convention has changed
slightly with the new version of OS
-
boot (1 Sep 93). The following
registers are in
itialized and then "pushed" onto the TCB:



gr1 :

register stack
-

4


rab:

register stack
-

128


pc0:

task + 4


pc1:

task


ops:

supervisor mode, interrupts enabled, I/O mask (if needed)


lr1:

register stack


rfb:

register stack


msp:

memory stack


Regist
ers that don't need initialization must also be reserved space in
the TCB. The register stack is initialized with the following values:



rstk
-

2 (lr2):

pointer to task's data


rstk
-

3 (lr1):

register stack


rstk
-

4 (lr0):

OSStartHighRdy (routine that
restores task
context)


Upon initial invokation of a task, control is transferred to the routine
OSStartHighRdy, which swaps in the task's TCB and starts the task
running.




Synchronous Task Switch



A synchronous task switch (or context switch) occurs w
hen a task
voluntarily gives up the processor so that another task can run. An
example of this is when a task wants to delay itself for a number of
clock ticks. All registers that pertain to the currently executing task
must be saved in the current task'
s context storage area. Certain global
registers, special registers, and the local registers need to be saved.
The shaded areas in Figure 1 are registers which do not need saving
during a synchronous context switch.


The signal number portion of the TCB
reflects which type of save
has been performed (sync or async). This way, when the task's context is
restored at a later time, it can be determined from the signal number
which registers need restoring.


?EMBED PBrush
\
s
\
* mergeformat???





Async. Save Frame


Sync. Save
Frame



Figure 1
-

TCB Layout




Asynchronous Task Switch



An asynchronous task switch occurs when the current task is
interrupted and must give up the processor to enable another task to
execute. This can happ
en when a timer interrupt occurs and a task with a
higher priority than the currently executing task has been made ready to
execute. Since the task has been interrupted, it is impossible to
determine what state the registers are in. For this reason, all

registers must be saved (see Figure 1).




Timer Initialization




A clock tick is an interrupt that occurs at system
-
defined
intervals. The tick rate currently defined is 1/10 of a second. This
value can be modified for each application. It should be
noted that the
shorter the system tick, the higher the overhead imposed on the system.
In addition, if the application supports a large number of tasks, there
will need to be a sufficiently long clock tick during which all tasks may
be serviced.






Trap

Vector Initialization



The Am29200 microcontroller vector table is initilialized with all
UCOS interrupt and trap handlers. Interrupt and/or trap handlers defined
in your application (e.g., parallel interrupts) can easily be added to
InitTbl, a table o
f vector numbers along with their associated handlers
in the file ucos29ka.s. Handlers are installed during initialization by
traversing InitTbl. The file stats.ah contains the currently assigned
vector numbers.



Timer Interrupt



The timer ISR (Interru
pt Service Routine) saves the currently
running task's context (async. save), then calls the C
-
level routine
OSTimeTick(). This routine is run with interrupts enabled to reduce
interrupt latency. Each task's TCB contains a field, OSTCBDly, which is
decr
emented for each timer tick. When OSTCBDly is decremented to zero,
the task is made ready to run. After the entire chain of tasks has been
traversed, the highest priority task's context is restored.




Section 2


Initialization of UCOS


The following s
teps are required to correctly initialize and start UCOS
on the Am29200 microcontroller:



1.

Set the operating mode to supervisor mode.


2.

Disable the timer.


3.

Call OSInit() to initialize all globals and create the idle
task.


4.

Create all semaphores
, mailboxes, and queues.


5.

Create your tasks.


6.

Start the timer.


7.

Call OSStart() to start multitasking.


The following #defines in ucos.h and ucos29kc.h should be changed to suit
your application:




TASK_STK_SIZE: this constant consists of the comb
ined values of the
TCB stack, register stack,



and memory stack.



OS_MAX_TASKS: defines the maximum number of tasks you wish UCOS to
manage.



OS_MAX_EVENTS: defines the maximum number of event control blocks
created by your




application. Each semap
hore, mailbox,
and queue requires an event control




block.



OS_MAX_QS: defines the maximum number of message queues created by
your application.


The following .equ constant should be defined in the stats.ah file:



CYCLES_PER_TICK: defines the number

of cycles per system tick.


Section 3


UCOS Files


The following files must be included with your application files:



ucos.c:


UCOS microprocessor
-
independent C source code


ucos29kc.c:

Am29200 microprocessor
-
specific C source code


ucos29ka.s:

Am29200 m
icroprocessor
-
specific assembly source code