（一）實習題目：Real-Time OS

（二）實習目的：This lab is a guide to Real-time Operating System (RTOS) in SoC design. This lab is based on μC/OS-II, a compact but complete RTOS shipped with ARM Firmware Suite (AFS). Internal mechanism of μC/OS-II is beyond the scope of this lab. For more detailed information about μC/OS-II, please refer to the book “MicroC/OS-II, the real-time kernel” by Jean J. Labrosse.

（三）原理：1. About μC/OS-II

Soft Real-time – tasks are performed as fast as possible Portable – runs on architectures ranging from 8-bit to 64 bit Scalable – features are configurable at compile time Multitasking – support 64 tasks simultaneously; including 8 reserved tasks Preemptive – preemptive multi-tasking with priority scheduling Kernel Services – provides task, time, memory management API; inter-process

communication API; task synchronization API Nested Interrupt – up to 255 levels of nested interrupt Priority Inversion Problem – does not support priority inheritance Not using MMU – no well protected memory space like Unix or Win

2. Task in μC/OS-II

Task is a single instance of program Task thinks it has all CPU control itself Task has its own stack and own set of CPU registers backup in its stack Task is assigned a unique priority (highest 0 ~ lowest 63) Task is an infinite loop and never returns Task has states (see Figure 1) μC/OS-II saves task records in Task Control Block(TCB)

Figure 1 Task states in uC/OS-II

Task States in μC/OS-II:

Running – task has control of the processor and executing its job Ready – task is ready to execute but its priority is less than the running task Waiting – task requires the occurrence of an event to continue ISR – task is paused because the processor is handling an interrupt Dormant – task resides in memory, but not seen by the scheduler

3. Task Scheduling & Context Switch

In μC/OS-II, task scheduling is performed on following conditions:

A task is created/deletedA task changes state On interrupt exit On post signal On pending event On task suspension

If the scheduler chooses a new task to run, context switch occurs. First, the context (processor registers) of current running task is saved in its stack. Next, the context of the new task is loaded into the processor. Finally, the processor continues execution. (see Figure 2)

Figure 2 Context switch in uC/OS-II

4. Coding Guidelines for Embedded RTOS

Coding for a program to run on embedded RTOS is slightly different from coding for PC. In an embedded application, workloads and available resources are known at design time. Hence, the designer should carefully explore the design space and optimize for short latency, small memory footprint, low power…etc.

When writing programs for μC/OS-II, some rules should be noticed:

Resources Use μC/OS-II defined data types for consistency & portability Use statically allocated local variables for preemptive multitasking Use semaphore to protect global variables and resources

Data transfer Inter-task communication can be achieved by mailbox/queue μC/OS-II & user program all run in privileged mode, use share memory with

caution!

Memory allocation Use μC/OS-II Kernel API: OSMemCreate(), OSMemGet()

Standard C library Many standard routine works in semihosting mode but not in stand-alone mode.

(e.g. printf, fopen)

5. Starting μC/OS-II

μC/OS-II is initialized and started in the main function. The initialization order is important.

1. Initialize ARM target2. Initialize OS3. OS create/allocate resources4. Create an initial task with highest priority5. Create other user tasks6. OS start scheduling7. In the initial task, enable global interrupt8. the initial task deletes itself9. Now, all other tasks runs under the control of OS

Note that you must create at least one task before OS start scheduling. Otherwise, you don’t get a chance to start any task and the system remains in idle state.

If an interrupt occurs before OS starts scheduling, the scheduler doesn’t know which tasks to run on interrupt exit and the system crashes. So, we introduce an initial task to enable global interrupt. This is for safety, but not required.

6. Resource management using Semaphore

Semaphore is used to represent the status of a resource. To use a shared resource such as I/O port, hardware device or global variable, you must request the semaphore from OS and release the semaphore after access (see Figure 3).

Figure 3 Resource management using Semaphore

Hiding the semaphore within device driver enables easy access to the hardware. IP vender can provide a set of API for the IP. Programmers don’t need to deal with detailed IP configuration and complex OS resources management scheme (see Figure 4).

Figure 4 Hiding Semaphore from tasks

7. Inter-Process Communication using Mailbox

In μC/OS-II, tasks are not allowed to communicate to each other directly. The communication must be done under control of OS through Mailbox (Figure 5). A Queue is an array of mailbox with FIFO or FILO configuration.

Figure 5 Inter-Process Communication using Mailbox

8. Memory Management

In μC/OS-II, memory allocation is semi-dynamic. Programmer must statically allocate a memory and partition the region using μC/OS-II Kernel API. Tasks can only request pre-partitioned fixed-size memory space from μC/OS-II (Figure 6). Using dynamic allocation such as malloc() is not prohibited but strongly discouraged.

Figure 6 Memory allocation in uC/OS-II

9. Setting up the ARMulator

The ARMulator can function as virtual prototype to various ARM core and development boards. However, the original configuration of ARMulator does not match that of ARM Integrator/AP. To run μC/OS-II on ARMulator, you need to follow the configuration steps in the reference section.

（四）實驗設備及儀器：1. Software：ADS1.2，AFS1.4.1

（五）引導實驗(方法)：

Building μC/OS-II1. Open μC/OS-II project file in ./Lab08/Codes/SW/ucos2/ with Code Warrior.2. Edit OS_CFG.H to customize μC/OS-II.

The configuration of μC/OS-II is done through a number of #define derivatives found

in OS_CFG.H. Basically, the default settings in OS_CFG.H work fine. You might want to disable some unused features or decrease some value of settings for more compact memory footprint on final release.

Option Values Description

OS_MAX_EVENTSdefault: 20

range: >=2

Maximum number of event control block available. The

value should be greater than the total number of mailbox,

semaphore and queue required by application.

OS_MAX_MEM_PARTdefault: 10

range: >=2

Maximum partitions to be managed by memory partition

manager. Note that OS_MEM_EN must be set to 1 first.

OS_MAX_QSdefault: 5

range: >=2

Maximum number of queue available in system.

OS_MAX_TASKSdefault: 62

range: 62~2

Maximum number of task can exist at a time. Note that

although μC/OS-II can handle 64 tasks but it reserves 2

tasks for itself.

OS_LOWEST_PRIOdefault: 63

range: 63~1

Specifies the lowest task priority (i.e., highest number) that

you intend to use.

OS_TASK_IDLE_STK_SIZE default: 512

Stack size (in 16-bit entries) for IDLE_TASK. The minimum

stack size depends on processor type and deepest interrupt

level allowed. It’s better to use default setting.

OS_TASK_STAT_EN default: 0

Statistic task computes CPU usage once every second.

The priority of statistic task is always set to

OS_LOWEST_PRIO-1.

OS_TASK_STAT_STK_SIZE default: 512Stack size (in 16-bit entries) for STAT_TASK. It is suggested

to use default value.

OS_CPU_HOOKS_EN default: 1

This setting indicates whether hook functions should be

included or not. hook functions are declared in

OS_CPU_C.C.

OS_MBOX_EN default: 1This enables or disables code generation of message

mailbox service.

OS_MEM_EN default: 0This enables or disables code generation of memory

partition manager and its associated data structures.

OS_Q_EN default: 1This enables or disables code generation of message queue

service.

OS_SEM_EN default: 1This enables or disables code generation of semaphore

manager.

OS_TASK_CHANGE_PRIO_EN default: 0 This indicates whether tasks can change priority at runtime.

OS_TASK_CREATE_EN default: 1 This enables support for standard task creation function.

You can choose either standard or extended version of task

creation function. If you wish, you can use both.

OS_TASK_CREATE_EXT_EN default: 0This enables support for extended task creation function.

Extended version delivers more powerful control over task.

OS_TASK_DEL_EN default: 0 This enables or disables task deletion capability.

OS_TASK_SUSPEND_EN default: 1 This enables or disables task suspension capability

OS_TICKS_PER_SEC default: 200This constant specifies the rate at which OSTimeTick() is

called. Better leave this untouched.

Table 1 uC/OS-II configuration options in OS_CFG.H

3. In target settings dialog, turn to Language Settings > ARM C Compiler > Preprocessor. Add INTEGRATOR to List of #DEFINEs to generate specific code for Integrator. (see Figure 7)

Figure 7 Define INTEGRATOR to generate specific code

4. At last, add 2 directories to the Access Path so header files could be found. In target settings dialog, select Target > Access Paths. Add ${AFS_ROOT}/AFSv1_4/Source/uHAL/h/ and ${AFS_ROOT}/AFSv1_4/Source/uHAL/Boards/INTEGRATOR/ as shown in Figure 8.

Figure 8 Adding access path for ARMuHAL library

5. Press the Make button, μC/OS-II library should be built successfully. A static library ucos2.a is created. Check the file in your working directory.

Building Program with μC/OS-II1. In Code Warrior, create a new project named “eg1” of type “ARM Executable

Image”. We assume the project is located at ./Lab08/Codes/SW/eg1/.

2. Add eg1.c to the project.

3. Add μC/OS-II as a sub-project. This enables automatic rebuilt of sub-project whenever necessary. This approach is more flexible than add the pre-compiled ucos2.a library file. (see Figure 9)

------ Note ------When adding sub-projects, a popup message might appear indicating that some Access Path is added. This is ok.--------------------

4. Add ARM uHAL library as a sub-project. The project file is located in ${AFS_ROOT}\Source\uHAL\Build\Integrator.b\uHALlibrary.mcp. (see Figure 9)

------ Note ------

The uHAL library is board specific. Choose the project file that matches your development board. We choose “Integrator.b” for Integrator/AP.--------------------

Figure 9 Adding uC/OS-II and uHAL as sub-projects

5. Now, specify which target to build and link. In project window, click the Target tab to display the Targets view for the project. Then, click the plus sign next to a build target containing the subproject to expand the hierarchy. Each build target in the subproject is listed in the hierarchy (see Figure 10).

Figure 10 build target hierarchy view

6. Click on the Target icon next to the subproject build targets you want to build along with the main project. The CodeWarrior IDE displays an arrow and target icon for selected build targets (see Figure 11).

7. Click in the Link Column next to the subproject build targets. Select the target you want to link with the main project (see Figure 11).

Figure 11 Select target to build and link with

------ Note ------You are free to create link dependencies to any of the build targets in a subproject. However, semihosted target must be selected for uHAL in order to support debugging with AXD.--------------------

------ Note ------The μC/OS-II shipped with AFS has been tested, so you can select Release target for to focus on debugging user application only.--------------------

8. Define SEMIHOSTED for programs to run in semihosted mode. In semihosted mode, an extra space of 1K bytes is needed for stack.

9. Build the main project. An executable file that contains both user application and operating system will be created.

10.Press Run button, you can see programs running on μC/OS-II in AXD console window. (see Figure 12)

targets to link with

Figure 12 uC/OS-II program running in AXD

Porting Program to μC/OS-II1. Open the project “eg2” at ./Lab08/Codes/SW/eg2/ with CodeWorrior.

2. The original code of eg2.c is listed in Error: Reference source not found. This program asks user for name and age, then it prints greeting message.

Figure 13 Original code of eg2

3. To port the program to μC/OS-II, include “includes.h” in eg2.c. The header file is an interface for μC/OS-II.

Figure 14 Including μC/OS-II interface in your code

1234567891011121314151617181920

#include <stdio.h>

int main(void){

char name[64];int age;

printf("please enter your name: ");scanf("%s", name);

do{

printf("please enter your age: "); scanf("%d", &age);

}while(age < 0);

printf("Hello, %s. Nice to meet you!\nYour age is %d.\n", name, age);

return(0);}

123

#include "includes.h" /* uC/OS-II interface */

#include <stdio.h>

4. Change the function name from main() to Task1() as shown in Figure 15. In addition, change return type from int to void because a task never returns. Remove the return statements, too.

Figure 15 Changes from Main() to Task1()

5. A task must receive an argument of type (void*), so change argument list from void to void *pdata as in Figure 15. The purpose of this pointer is to pass initialization value to task.

Figure16 Warp task body with an infinite loop

6. A task is an infinite loop, so wrap the codes with a for loop (see Error: Referencesource not found). Remember, all task should call at least one kernel service in its code body. Otherwise, the multitasking mechanism of μC/OS-II will not work. You can call OSTimeDly() service to pause for a while after each round of processing, allowing lower priority task to execute.

7. Insert a new main function as shown in Figure 18 at the bottom of eg2.c. In the main function, create an instance for Task1.

123456

void Task1(void *pdata){……return(0); <= remove this!}

12345678910

void Task1(void *pata){ for(;;) { // user code … …

OSTimeDly(100);}

}

Figure 17. Syntax for OSTaskCreate()

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

int main(int argc, char *argv[])

{

/* do target (uHAL based ARM system) initialization */

ARMTargetInit();

/* needed by uC/OS */

OSInit();

/* create the tasks in uC/OS */

OSTaskCreate(Task1, (void *)0, (void*)&Stack1[STACKSIZE - 1], 3);

/* Start the (uHAL based ARM system) system running */

ARMTargetStart();

/* start the game */

OSStart();

/* never reached */

return(0);

}

Figure 18. Code for main() that creates an instance of Task1()

8. Insert the following code near the top of eg2.c to create a stack for Task1. Each task must have its own stack. The actual stack size needed depends on processor type, depth of interrupt allowed and the work your task is running…etc. System crashes on stack overflow. So, it’s better to allocate a bigger stack first than try to decrease the value.

OSTaskCreate(void (*task)(void* pd), void *pdata, OS_STK *ptos, INTU8 prio)

Arguments:

*task pointer to the task’s code*pdata pointer for passing arguments*ptos pointer to top of stackprio unique priority for each task. smaller number means higher priority

Figure 19. Define stack size and create resources for task

9. Build the project and press Debug to run. The task runs repeatedly asking name and age.

Figure 20. Application running in AXD console

Using Inter-Process Communication (IPC)To communicate between process, you must call OS service: message mailbox or message queue. Build and run project eg3 to learn about IPC. This program does the very same thing as eg2 does. However, eg3 use one task for input and another task for output. Data is passed between tasks using Mailbox.

1. Open project “eg3” in ./Lab08/Code/SW/eg3/ with CodeWorrior.

2. Because multiple value are to be passed, declare a structure to hold the values.

3. We will trace uC/OS-II IPC machenism, so link Debug target of uC/OS-II.

12345678

/* allocate memory for tasks' stacks */#ifdef SEMIHOSTED#define STACKSIZE (64+SEMIHOSTED_STACK_NEEDS)

#else#define STACKSIZE 64

#endif

OS_STK Stack1[STACKSIZE];

------ Note ------If Debug is not enabled for uC/OS-II, you will get assembly code view but not C code view when tracing IPC execution.--------------------

4. Build project and start AXD for Debug

5. Set a break point near line 75 in Task1, where Task1 posts mail to the mailbox. (see Figure 21)

6. Use “Step In (F8)” to trace into the OSMboxPost(). The cursur should Jump to OSMboxPost() function in “os_mbox.c”.

7. Next, use “Step (F10)” to trace how message is delivered from Task1 to Task2.

8. When you reach “OSSched()” function, use “Step in” again to trace into the scheduler.

Figure 21 Set a break point at OSMboxPost()

9. When you reach “OS_TASK_SW()” function, use “Step in” again.

10. Finally, you reach Task2 near line 88. Where Task2 pending on the mailbox. (see Figure 22)

Figure 22 Arrive at OSMboxPend in Task2

（六）實驗要求：Write an ID checking engine and a front–end interface. The checking rule is in the reference section.

Requirements: The engine and front-end must be implemented in different task. The front-end interface can accept up to 64 entries of ID in each round. The program runs continuously round by round.

User input: The amount of ID to be checked. The ID numbers

Program output: The ID number Check result

Example:

(start of round)How many IDs to check: 2Enter ID #1: A123456789Enter ID #2: B987654321=== check result ===

A123456789 validB987654321 invalid(end of round)

（七）問題與討論：What are the advantages of using RTOS in SoC design? And what are the disadvantages?

（八）參考文件與網頁：Information about μC/OS-II http://www.ucos-ii.com/ “MicroC/OS-II, the real-time kernel” (ISBN: 0-87930-543-6)

Setting up ARMulatorThe ARMulator can simulate various ARM cores and ARM development boards. To make ARMulator behave like an ARM7TDMI running on an Integrator/AP board, just follow these steps.

1. Redefine peripheral I/O mapping in high-level model.

Edit C:\Program Files\ARM\ADSv1_2\ARMulate\armulext\timer.c. Find the following code segment near line 129. Change timer’s I/O base address and range to 0x13000000 and 0x300, respectively (see Error: Reference source not found). This high-level module simulates TIMER1 & TIMER2 on Integrator/AP.

1

2

3

4

err = ARMulif_ReadBusRange(&state->coredesc, state->hostif,

ToolConf_FlatChild(config, (tag_t)"RANGE"),

&state->my_bpar,

0x0a000000,0x40,"");

Figure 23 Original code of timer.c

1

2

3

4

err = ARMulif_ReadBusRange(&state->coredesc, state->hostif,

ToolConf_FlatChild(config, (tag_t)"RANGE"),

&state->my_bpar,

0x13000000,0x300,"");

Figure 24 Modified timer.c for Integrator/AP

Go to line near 640. Rewrite the code calculating the offset of an access event.

Figure 25 Original code for calculating offset address

Figure 26 Modified code

Go to line near 650, where you will see a switch(maskedAddress) statement. Edit each case item so the offset values are correct.

1

2

3

4

5

6

7

8

9

10

11

12

case 0x100: /* Timer1Load */

/* Only the bottom 16 bits are significant */

*word = ts->timer1.TimerLoad & 0x0000FFFF;

break;

case 0x104: /* Timer1Value */

/* We need to work out what this value is at present. */

*word = ValueRegRead(ts, &ts->timer1);

break;

case 0x108:/* Timer1Control*/

*word = ts->timer1.TimerControl;

/* nothing to do apart from give it back */

break;

Figure 27 PARTIAL codes that defines behavior for each address

------ Note ------There are 3 timers on Integrator/AP, but timer.c only defines 2 timers. Fortunately, μC/OS-II does not use TIMER0. So, you can map the two timers in timer.c to 0x13000100 for TIMER1 and 0x13000200 for TIMER2.---------------------

Re-compile and install the high-level model for timer. In command line, go to C:\

1 unsigned long maskedAddress = addr & 0x000003FF;

1 unsigned long maskedAddress = ((unsigned long) addr - (0x13000100));

Program Files\ARM\ADSv1_2\ARMulate\armulext\timer.b\intelrel\ and run nmake (you must have Visual C++ 6.0 installed). Then, copy timer.dll to C:\Program Files\ARM\ADSv1_2\Bin.

Edit corresponding section in peripherals.ami and peripherals.dsc for timer. Note that only I/O base address is specified. ARMulator will use default value specified in timer.c for I/O range (see Figure 28, Figure 29).

Figure 28 Redefine timer in peripherals.ami

1

2

3

4

5

6

7

8

9

10

11

12

13

{Timer

meta_sordi_dll=Timer

META_GUI_INTERFACE=Timer

Waits=0

Range:Base=0x13000100

CLK=20000000

TicMCCfg=2

IntOne=6

IntTwo=7

}

{No_Timer=Nothing

META_GUI_INTERFACE=Timer

}

Figure 29 Redefine timer in peripherals.dsc

Repeat step 1~5 for interrupt controller according to Table 3. The high-level model for interrupt controller is intc.c. The intc.c only defines one interrupt controller while Integrator/AP has three. Again, you map the only interrupt controller to 0x14000000 for IRQ0 (see Table 3).

Restart AXD to take effect.

1234567

{Default_Timer=TimerWaits=0Range:Base=0x13000100CLK=20000000IntOne=6IntTwo=7}

2. Configure Processor

Start AXD, and then select Options > Configure Target from menu. Choose ARMUL(ARMulator) as target and then press Configure button on the left.

Configure ARMulator as below.

Processor: ARM7TDMIClock: Real-timeMemory Map File: No Map File

I/O registers for Timer & Interrupt Controller

Address Name Type Size Function

0x13000000TIMER0

_LOAD

Read/

Write16 Timer 0 load register

0x13000004TIMER0

_VALUERead 16 Timer 0 current value register

0x13000008TIMER0

_CTRL

Read/

Write16 Timer 0 control register

0x1300000cTIMER0

_CLRWrite 1 Timer 0 clear register

0x13000100TIMER1

_LOAD

Read/

Write16 Timer 1 load register

0x13000104TIMER1

_VALUERead 16 Timer 1 current value register

0x13000108TIMER1

_CTRL

Read/

Write16 Timer 1 control register

0x1300010cTIMER1

_CLRWrite 1 Timer 1 clear register

0x13000200TIMER2

_LOAD

Read/

Write16 Timer 2 load register

0x13000204TIMER2

_VALUERead 16 Timer 2 current value register

0x13000208TIMER2

_CTRL

Read/

Write16 Timer 2 control register

0x1300020cTIMER2

_CLRWrite 1 Timer 2 clear register

Table 2 Memory map for Timer on Integrator/AP

Address Name Type Size Function

0x14000000IRQ0_ST

ATUSRead 22 IRQ0 Status

0x14000004IRQ0_RA

WSTATRead 22 IRQ0 interrupt request status

0x14000008

IRQ0_EN

ABLESE

T

Read/

Write22 IRQ0 enable set

0x1400000c

IRQ0_EN

ABLECL

R

Write 22 IRQ0 enable clear

Table 3 Memory map for interrupt controller on Integrator/AP

You can find more information in “Integrator/AP ASIC Dev Platform” section “Programmer’s Reference”. The document is available at www.arm.com Document User Guides.

ID Checking Rules ID number comes in a 10-digit set. The ID starts with an alphabet, followed by 9

digits of numeral. Check the first numeral, it should be either “1” or “2”. Transform the alphabet into 2 digits. Use Figure 30 for transformation.

ID A 1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 7 8 9 1

A B C D E F G H I J K L M10 11 12 13 14 15 16 17 34 18 19 20 21N O P Q R S T U V W X Y Z

22 35 23 24 25 26 27 28 29 30 31 32 33

Figure 30 Transform table for alphabet

Multiply each digit with its weighting and sum them up.

Digit Weighting

0 1 2 3 4 5 6 7 8 9

9 8 7 6 5 4 3 2 1 1 1

1

130)1918273645546372819011(

The summation of a valid ID should be devisable by 10.

130 mod 10 = 0 valid