Lab04 Real Time OS - access.ee.ntu.edu.twaccess.ee.ntu.edu.tw/course/soc2003/soc material version...

Contents 4. Real-Time OS..........................................................4-1

4.1. 實驗目的 ................................................................................................. 4-1 4.2. 實驗原理 ................................................................................................. 4-1

4.2.1. About µC/OS-II ........................................................................ 4-1 4.2.2. Task in µC/OS-II...................................................................... 4-1 4.2.3. Task Scheduling & Context Switch...................................... 4-2 4.2.4. Coding Guidelines for Embedded RTOS ............................ 4-3 4.2.5. Starting µC/OS-II ..................................................................... 4-4 4.2.6. Resource management using Semaphore ......................... 4-4 4.2.7. Inter-Process Communication using Mailbox..................... 4-6 4.2.8. Memory Management ............................................................ 4-6 4.2.9. Setting up the ARMulator....................................................... 4-7

4.3. 引導實驗 ................................................................................................. 4-7 4.3.1. Building µC/OS-II .................................................................... 4-7 4.3.2. Building Program with µC/OS-II..........................................4-10 4.3.3. Porting Program to µC/OS-II ...............................................4-12 4.3.4. Using Inter-Process Communication (IPC).......................4-15

4.4. 實驗要求 ...............................................................................................4-17 4.5. 問題與討論 ...........................................................................................4-17 4.6. 參考文件及網頁 ...................................................................................4-18

4.6.1. Information about µC/OS-II .................................................4-18 4.6.2. Setting up ARMulator ...........................................................4-18 4.6.3. ID Checking Rules ................................................................4-21

Real Time OS

教育部 SOC聯盟教材 4-1

4. Real-Time OS

4.1. 實驗目的

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.

4.2. 實驗原理

4.2.1. About µC/OS-II

l Soft Real-time – tasks are performed as fast as possible l Portable – runs on architectures ranging from 8-bit to 64 bit l Scalable – features are configurable at compile time l Multitasking – support 64 tasks simultaneously; including 8 reserved

tasks l Preemptive – preemptive multi-tasking with priority scheduling l Kernel Services – provides task, time, memory management API; inter-

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

4.2.2. Task in µC/OS-II

l Task is a single instance of program l Task thinks it has all CPU control itself l Task has its own stack and own set of CPU registers backup in its

stack l Task is assigned a unique priority (highest 0 ~ lowest 63) l Task is an infinite loop and never returns l Task has states (see Figure 1) l µC/OS-II saves task records in Task Control Block(TCB)

Real-Time OS


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

4.2.3. Task Scheduling & Context Switch

In µC/OS-II, task scheduling if performed on following conditions:

♦ A task is created/deleted ♦ A 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)

Real Time OS


Figure 2 Context switch in uC/OS-II

4.2.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 − User µ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

Real-Time OS


♦ 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)

4.2.5. Starting µC/OS-II

µC/OS-II is initialized and started in the main function. The initialization order is important. 1. Initialize ARM target 2. Initialize OS 3. OS create/allocate resources 4. Create an initial task with highest priority 5. Create other user tasks 6. OS start scheduling 7. In the initial task, enable global interrupt 8. the initial task deletes itself 9. 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.

4.2.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).

Real Time OS


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

Real-Time OS


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

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

Real Time OS


Figure 6 Memory allocation in uC/OS-II

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

4.3. 引導實驗

4.3.1. Building µC/OS-II

1. Open µC/OS-II project file in ./Lab5/Codes/SW/ucos2/ with Code Warrior.

2. Edit OS_CFG.C 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.

Real-Time OS


Option Values Description

OS_MAX_EVENTS default: 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_PART default: 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_QS default: 5 range: >=2 Maximum number of queue available in system.

OS_MAX_TASKS default: 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_PRIO default: 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: 512 Stack 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: 1 This enables or disables code generation of message mailbox service.

OS_MEM_EN default: 0 This enables or disables code generation of memory partition manager and its associated data structures.

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

OS_SEM_EN default: 1 This 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: 0 This 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: 200 This constant specifies the rate at which OSTimeTick() is called. Better leave this untouched.

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

Real Time OS


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

Real-Time OS


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.

4.3.2. Building Program with µC/OS-II

1. In Code Warrior, create a new project named “eg1” of type “ARM Executable Image”. We assume the project is located at ./Lab4/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

Real Time OS


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

targets to link with

targets to build

Build targets for μC/OS-II

Build targets for uHAL

Real-Time OS


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

Figure 12 uC/OS-II program running in AXD

4.3.3. Porting Program to µC/OS-II

1. Open the project “eg2” at ./Lab4/Codes/SW/eg2/ with CodeWorrior. 2. The original code of eg2.c is listed in Figure 13. This program asks

user for name and age, then it prints greeting message.

Real Time OS


1 2 3

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#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);

}

1 2 3 4 5 6 7 8 9 10

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

} }

1 2 3 4 5 6

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

Figure 13. Original code of eg2.c

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

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.

Figure 16. Warp task body with an infinite loop

Real-Time OS


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 stack prio ð unique priority for each task. smaller number means higher priority

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); }

1 2 3 4 5 6 7 8

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

#else #define STACKSIZE 64

#endif OS_STK Stack1[STACKSIZE];

6. A task is an infinite loop, so wrap the codes with a for loop (see Figure 16). 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.

Figure 17. Syntax for OSTaskCreate()

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.

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.

Real Time OS


Figure 20. Application running in AXD console

4.3.4. 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 ./Lab4/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. ------ 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.

Real-Time OS


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

Real Time OS


4.4. 實驗要求

Write an ID checking engine and a front–end interface. The checking rule is in the reference section. Requirements: l The engine and front-end must be implemented in different task. l The front-end interface can accept up to 64 entries of ID in each round. l The program runs continuously round by round.

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

Program output: l The ID number l Check result

Example: (start of round) How many IDs to check: 2 Enter ID #1: A123456789 Enter ID #2: B987654321 === check result === A123456789 valid B987654321 invalid (end of round)

4.5. 問題與討論

What are the advantages of using RTOS in SoC design? And what are the disadvantages?

Real-Time OS


1 2 3 4

err = ARMulif_ReadBusRange(&state->coredesc, state->hostif, ToolConf_FlatChild(config, (tag_t)"RANGE"), &state->my_bpar, 0x0a000000,0x40,"");

1 2 3 4

err = ARMulif_ReadBusRange(&state->coredesc, state->hostif, ToolConf_FlatChild(config, (tag_t)"RANGE"), &state->my_bpar, 0x13000000,0x300,"");

1 unsigned long maskedAddress = addr & 0x000003FF;

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

4.6. 參考文件及網頁

4.6.1. Information about µC/OS-II

♦ http://www.ucos-ii.com/ ♦ “MicroC/OS-II, the real-time kernel” (ISBN: 0-87930-543-6)

4.6.2. Setting up ARMulator

The ARMulator can simula te 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 Figure 24). This high-level module simulates TIMER1 & TIMER2 on Integrator/AP.

Figure 23 Original code of timer.c

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.

Real Time OS


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 }

1 2 3 4 5 6 7

{Default_Timer=Timer Waits=0 Range:Base=0x13000100 CLK=20000000 IntOne=6 IntTwo=7 }

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:\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). Interrupt numbers must also be specified according to 錯誤! 找不到參照來源。.

Figure 28 Redefine timer in peripherals.ami

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

Real-Time OS


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.

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: ARM7TDMI Clock: Real-time Memory Map File: No Map File I/O registers for Timer & Interrupt Controller Address Name Type Size Function

0x13000000 TIMER0_LOAD Read/Write 16 Timer 0 load register

0x13000004 TIMER0_VALUE Read 16 Timer 0 current value register

0x13000008 TIMER0_CTRL Read/Write 16 Timer 0 control register 0x1300000c TIMER0_CLR Write 1 Timer 0 clear register



0x13000108 TIMER1_CTRL Read/Write 16 Timer 1 control register

0x1300010c TIMER1_CLR Write 1 Timer 1 clear register



0x13000208 TIMER2_CTRL Read/Write 16 Timer 2 control register

0x1300020c TIMER2_CLR Write 1 Timer 2 clear register

Table 2 Memory map for Timer on Integrator/AP

Address Name Type Size Function

0x14000000 IRQ0_STATUS Read 22 IRQ0 Status

0x14000004 IRQ0_RAWSTAT Read 22 IRQ0 interrupt request status

0x14000008 IRQ0_ENABLESET Read/Write 22 IRQ0 enable set 0x1400000c IRQ0_ENABLECLR 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.

Real Time OS


4.6.3. ID Checking Rules

l ID number comes in a 10-digit set. The ID starts with an alphabet, followed by 9 digits of numeral.

l Check the first numeral, it should be either “1” or “2”. l 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 M 10 11 12 13 14 15 16 17 34 18 19 20 21 N 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

l 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( =×+×+×+×+×+×+×+×+×+×+×

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

130 mod 10 = 0 ð valid

Lab04 Real Time OS - access.ee.ntu.edu.twaccess.ee.ntu.edu.tw/course/soc2003/soc material version...

Documents

Transcript of Lab04 Real Time OS - access.ee.ntu.edu.twaccess.ee.ntu.edu.tw/course/soc2003/soc material version...