RTOS Interface 의 비교

(1)

Technical Notes / www.novonetworks.com Classification : RTOS

RTOS Interface 의 비교

Technical comparison of RTOS Interfaces

Release 1.1

2004/11/8

(2)

RTOS Interface 의 비교 1.1

All information contained herein is the property of novo networks. No part of this publication (whether in hardcopy or electronic form) may be reproduced or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of novo networks.

No responsibility is assumed by novo networks for the use thereof nor for the rights of third parties which may be effected in any way by the use thereof. Any representation(s) in this document concerning performance of novo networks’ product(s) are for informational purposes only and are not warranties of future performance

VxWorks and pSOS are registered trademarks of Wind River Systems, Inc.

Nucleus is a trademark of Mentor Graphics Corporation.

VRTX is a registered trademark of Mentor Graphics Corporation.

VRTXsa is a trademark of Mentor Graphics Corporation.

uC/OS and MicroC/OS are registered trademarks of Micrium, Inc.

uC/OS-II and MicroC/OS-II are trademarks of Micrium, Inc.

All other trademarks, service marks, registered trademarks, or registered service marks may be the property of their respective owners. All specifications are subject to change without prior notice.

(3)

목 차 (Table of Contents)

1. AUDIENCE ... 4

2.

작성 배경... 5

3.

비교 범위... 6

3.1 TASK... 7

3.2 SEMAPHORE & MUTEX... 10

3.3 QUEUE... 13

3.4 EVENT FLAG... 16

3.5 MEMORY PARTITION... 18

3.5.1 Fixed-size Partition ... 20

3.5.2 Variable-size Allocation... 21

APPENDIX A.

문서정보... 22

A.1 문서이력... 22

(4)

1. Audience

본 자료는 리얼타임 임베디드(Real-time Embedded) 시스템에서 널리 사용되는 Thread 타입의 5 가지 RTOS 를 비교함으로써, RTOS 간의 차이점을 이해하고, 그로 인해 RTOS 에 대한 더 넓고 깊은 이해에 도움이 될 것으로 생각되어 만들어졌다.

따라서, 본 글의 독자는 적어도 하나의 Thread 방식의 RTOS 를 접하였다는 가정아래 작성되었다. 혹 그렇지 않다면, 하나의 RTOS 를 선택하여 깊게 공부한 뒤에 이 문 서를 참조하는 것이 바람직 할 것으로 보인다.

프로젝트가 시작되면 RTOS 를 선정하게 된다.

‘어떤 RTOS 를 사용하게 될까?’

우스개 소리이지만, 언제나 프로젝트 리더가 이전에 써본 RTOS 가 선정된다.

새로운 RTOS 를 사용하는 것은, 한국어를 쓰다가 영어로 바꾸는 것만큼 어려운 일인 듯 싶다. 그러나, ‘이제는 바꾸어야 되는데…’ 하면서 정작 수년동안 RTOS 를 바꾸 지 못하는 동료 엔지니어를 바라보면서, 굳이 용기를 내보라고 하고 싶다.

이 문서가 동료 엔지니어의 새로운 경험에 용기를 내는데, 조금이라도 도움이 되었 으면 하는 바람이다. 언제나 해보면 별것이 아니다.

(5)

2. 작성 배경

지난 수년간 많은 프로젝트를 수행하였는데, 프로젝트의 특성과 함께 일하는 회사의 경험에 따라 각각 다른 RTOS 를 사용한다. 결과적으로 프로젝트마다 다른 RTOS 를 사용하게 되는데, 문제는 내부 기술의 축적과 재사용을 위해 소프트웨어 모듈화를 수행 중이라는 점이다. 모듈의 기반인 RTOS 가 변경되면 각 모듈의 소스가 변경되 어진다. 그런데, 소스가 변경되면, 다시 시험을 해야 되기 때문에 100% 재사용이 가져 다 주는 이점을 대부분 잃어버리게 된다.

이런 이유로 수정 없이 사용할 수 있는 소프트웨어 모듈의 개발을 가능하도록 하는 RTOS-independent Layer, 즉, RTOS 에 관계없이 하나의 공통 RTOS Platform 을 만들자 는 시도가 이루어졌다. RTOS-independent Layer 가 존재하면 그 상위의 소프트웨어 모듈은 수정 없이 100% 재사용이 가능해짐으로 생산성은 물론이고 안정성에서 장점 을 가진다.

이런 목적으로 5 개 RTOS 에 대한 개념, Interface, Parameter, Return 값, Error Code 등을 포함한 상세한 분석이 이루어졌다. 결과로 70 여 페이지의 분석자료와, 200 여 페이 지의 RTOS-independent Layer 의 규격이 만들어졌다. 참고로 VxWorks, VRTXsa, Nucleus 에서는 프로젝트를 직접 수행하였으나, uC/OS II 와 pSOS 는 문서 레벨에서 검 토하였다.

본 문서는 위의 분석자료를 이해하기 쉽도록 단순화하고 정리하여 만들어졌다. 독 자가 가지고 있는 RTOS 의 배경에 따라서 용어도 조금씩 다르고, 개념 또한 상의할 것으로 보이나, 흐름상에서 놀랄만한 것은 없다고 보여진다.

이해가 되지 않는 부분이 있다면, 문서 맨 끝에 있는 연락처로 문의하기 바란다. 능 력이 되는 한, 도움이 되기를 희망한다.

(6)

3. 비교 범위

비교한 5 가지 RTOS 는 모두 Thread 방식의 분류에 해당되나, RTOS 마다 미세한 차 이점으로 보이고 있다. 비교 범위는 Kernel 부분의 interface 부분에 한정된다.

BSP 부분에 대한 내용은 포함되지 않는다.

비교부분은 아래와 같다.

Task

Semaphore & Mutex Queue

Event Flag Memory Partition Fixed-size Partition Variable-size Allocation

(7)

3.1 Task

일반

Thread 방식의 Task 의 개념은 대부분 유사하며, Task ID 의 관리 주체가 누구인가, Stack Size 의 설정 여부 등의 사소한 차이만을 보인다. 그러나, uC/OS II 의 경우 에는 좀 독특해서 Priority 를 Task ID 를 사용하는 방식을 채택하여, 그 중 독특하 다고 할 수 있다.

Task ID

Task 에 대한 Unique Key 는 모두 Task ID 를 사용한다. 그러나, 동일한 이름의 Task ID 이지만 속을 들여 다 보면 차이점이 발견된다. VxWorks 나 pSOS, Nucleus 의 경우에는 성능을 위해 TCB 의 pointer 를 Task ID 로 사용하고 있는 반면 VRTX 나 uC/OS II 는 Virtual Task ID 를 사용하고 Table 에서 TCB 를 찾아 사용하는 방식 을 사용하고 있다. VRTX 는 0, 1..255 까지 (1..255 or CFUTSKCT, 0 사용 시에는 Reference 할 수 없음 : Priority 를 이용하여 지정가능) 사용할 수 있으며 uC/OS II 의 경우에는 4..59 까지(0..63 으로 되어 있으나 uCOS 에서 아래 4 개 위의 4 개를 사용함) 사용할 수 있다. 이러한 방식의 차이에 따라 Task ID 를 지정하는 주체가 사용자 혹은 OS 가 되게 된다. VRTX 와 uC/OS II 의 경우에는 사용자가 Task ID 를 지정할 수 있도록 되어 있다. 이에 반해 VxWorks 나 pSOS, Nucleus 의 경우에 는 OS 가 TCB 를 할당 받고 그의 pointer 값을 넘겨주는 형식을 취하고 있다. 물 론 VxWorks 와 Nucleus 의 경우에 사용자 TCB 를 지정할 수 있지만 VRTX 나 uC/OS II 의 Task ID 와는 성격이 다르다고 할 수 있다.

Task 수의 제한

uC/OS II 의 경우에 56 개의 Task 를 만들 수 있다. 실제로는 64 개의 Task 를 만들 수 있으나, OS 에서 상위 4 개와 하위 4 개의 Task 를 사용하고 있으므로 사용자는 최대 56 개까지 사용할 수 있다. uC/OS II 를 제외한 4 개의 RTOS 에서는 Memory 가 가능한 만큼, 혹은 Configuration 의 최대치 만큼 생성이 가능함으로 RTOS 상 Task 의 수는 제한이 없다고 보아도 무난하겠다.

Task 의 이름

VRTX 와 uC/OS II 에서는 Task 의 이름을 지원하지 않는다. VxWorks, pSOS, Nucleus 에서는 이름을 지원하며 각각 10 자, 4 자, 8 자 길이를 지원한다. VxWorks

(8)

의 경우에는 길이의 제한이 없으나 지원 Tool 에서 10 자를 지원함으로 이를 추천 하고 있다. Task 의 이름은 사용자 입장에서 Task 에 대한 unique ID 역할을 하게 된다. 물론 동일한 ID 의 사용을 RTOS 에서 제한을 두고 있는 것은 아니지만 Task ID 를 사용자가 받아쓰도록 되어 있는 Mechanism 과 무관하지 않다고 볼 수 있다..

Priority

VxWorks, VRTX, Nucleus 의 경우에 0 에서 255 까지의 Priority 를 지원하며 0 이 가 장 높은 priority 를 갖는다. pSOS 의 경우도 0 부터 255 까지의 priority 를 사용할 수 있으나 OS 에서 0 과 240~255 를 사용하기 때문에 결과적으로 1 부터 239 까지 의 사용이 가능하다. 특이한 점은 pSOS 의 priority 는 0 이 가장 낮은 priority 를 나타낸다는 것이다. 이는, POSIX 의 priority 방침과 동일하다.

uC/OS 는 이 5 가지 RTOS 중에서 가장 특이한 OS 로서 Priority 가 Task ID 와 동 일하게 사용된다. uC/OS II 의 경우에는 0 부터 63 까지의 Priority 를 사용가능하나 위 4 개와 아래의 4 개 priority 를 제외한 4 부터 59 까지의 priority 의 사용만이 가 능하다. Priority = Task ID 의 공식에 따라 동일한 Priority 는 사용이 불가능하 다. 실제로 Task ID 라는 용어는 사용되지 않으며 (OSTaskCreateExt()의 id 가 있으 나 차후 upgrade 를 위한 argument 임) 모든 key 는 priority 를 사용한다. Priority 변 경 시에도 변경 후 priority 가 unique 여부를 확인하게 된다.

Task 생성단계

Task 를 생성하는 단계는 1 단계와 2 단계로 나뉜다. 1 단계는 생성 후 즉시 Scheduling 이 시작되는 경우이고 2 단계는 생성과 Scheduling 의 시작이 분리되어 있는 경우이다. Nucleus 와 uC/OS II 의 경우에는 1 단계를 지원한다. pSOS 의 경 우에는 항상 2 단계로 Task 를 생성하게 된다. VxWorks 와 VRTX 의 경우에는 1 단계와 2 단계 모두를 지원하고 있어, 총 3 개의 interface 가 사용된다. VRTX 의 경우, sc_tecreate() 사용하여 mode 를 suspend 하게 되며, sc_tresume()을 사용하여 resume 시킨다. VxWorks 에서는 taskInit()와 taskActivate()를 사용한다.

Argument Passing

Task 생성시에 생성 Task 에서 생성되는 Task 에게 Data 를 보내기 위하여 Argument 를 지원한다. Argument 는 RTOS 마다 독특한 형태를 취하고 있어 공통 점을 찾기 어렵다. VxWorks 의 경우에는 10 개의 integer argument 를 사용하도록 되어 있다. pSOS 의 경우에는 4 개를 사용할 수 있다. VRTX 의 경우에는 char

*paddr 과 unsigned long psize 의 형태를 띈 하나의 parameter block 을 보낼 수 있

(9)

다. Nucleus 의 경우에는 argc 와 argv 형태를 사용하며 uC/OS II 의 경우에는 3 개 의 parameter 를 보낼 수 있다.

노트 PAD 기능

이 기능은 pSOS 에서만 사용되는 개념으로, Notepad 란 Task 별 global variable 로서 어떤 Task 부터든 그 내용을 보고 쓰고 할 수 있다. Task 별로 16 개의 32-bit notepad register 를 지원하며 0~7 은 application 용으로 8~15 는 pSOS 가 사용한다.

t_getreg()와 t_setreg() interface 를 사용한다.

특수 interface

VxWorks 의 경우, taskRestart()로써 실행중인 task 를 재시작 시킬 수 있다.

taskCreateHookAdd()와 같이 Task 의 생성, 삭제 및 Task Switching 시 Hook 을 실행 시킬 수 있다. pSOS 도 t_restart()를 지원한다. pSOS 에서는 tm_evafter(), tm_evevery(), tm_evwhen() 와 같이 다양한 reliative 혹은 absolute timer 기능을 지원 한다.

Nucleus 에서는 NU_Check_Stack()으로 Stack 에 남아있는 양을 Check 할 수 있다.

NU_Reset_Task()은 VxWorks 의 Reset 과 약간 다르게, 종료된 task 를 재시작 시키 는 기능을 제공한다. 재시작후에는 resume 을 하여야 한다.

uC/OS II 에는 기존의 Delay 를 기다리는 Task 를 강제로 Ready 로 만드는 기능인 OSTimeDlyResume()을 지원한다.

(10)

3.2 Semaphore & Mutex

일반

Semaphore 는 크게 Counting Semaphore 와 1 과 0 을 가지고 있는 Binary Semaphore 의 특수 형태인 Mutex 로 구분된다. VxWorks 의 경우에는 Binary Semaphore 를 별 도의 형태로 구분하고 있으나 Count 가 1 인 Semaphore 와 크게 다르지 않다.

Mutex 지원

Nucleus 는 Mutex 를 지원하지 않는다.

pSOS 의 경우 pSOS 3 부터 지원을 하며, uC/OS II 는 2.04 부터 지원한다.

Priority or FIFO

Semaphore 에 pending 되는 형태에 따라 priority 와 FIFO 로 나뉜다. uC/OS II 의 경 우에는 Priority 만을 지원한다. 나머지 RTOS 는 priority 와 FIFO 모두를 지원하도 록 되어 있으며 이는 semaphore 생성 interface 에서 선택할 수 있도록 되어 있다.

SCB 의 관리

Nucleus 의 경우에는 Semaphore Control Block 을 사용자가 지정하도록 되어 있다.

Name 의 사용

pSOS 와 Nucleus 에서는 Semaphore 에 이름을 부여할 수 있다. 각각 4 자와 8 자를 지원하며 그 외의 RTOS 는 Name 을 지원하지 않고 단지 Semaphore ID 만을 사용 한다.

Mutex 의 Inversion Safe 기능

Mutex 의 기능 중 하나는 Priority inversion 에 대한 해결책으로 priority inheritance 기능을 제공하기 위함이다. 이 기능을 제공하는 OS 는 VxWorks 와 VRTX 이며, uC/OS II 와 pSOS 에서의 지원여부는 확인하지 못하였다.

참고로 Priority Inheritance 기능은 아래와 같다.

Semaphore 에 두개 이상의 Task 가 Pend 되는 경우, Semaphore 를 가지고 있는 Task 가 동안 해당 Semaphore 에 Pend 되어 있는 가장 높은 priority 를 inherit 받는 기능 이다. (낮은 priority 가 Semaphore 를 Give 할 때까지 높아짐)

낮은 priority 의 Task 가 Semaphore 를 가지고 있고 높은 Priority 의 Task 가 그

(11)

Semaphore 에 Pend 되어 있는 경우에, 중간 priority 의 Task 가 수행되는 경우에, Semaphore 를 가지고 있는 task 의 낮은 priority 로 인해 중간 Priority 의 Task 가 수 행되게 된다. 이로 인해 낮은 priority 의 Task 는 CPU 를 받지 못하게 되어 priority 가 높은 Task 또한 수행되지 않는 현상을 Priority Inversion 이라 한다. 이 를 방지하기 위하여 Priority inheritance 기능을 사용한다.

Timeout 중 No Wait 기능 형태

Semaphore 에서 Timeout 에는 3 가지를 지원한다 : Timeout, 무한대, No Timeout.

이 중에서 No Timeout, 즉 Semaphore 를 얻을 수 없는 경우에 Pend 되지 않고 즉 시 Return 되는 형태를 말한다. VxWorks, Nucleus 의 경우에는 NOWAIT 을 pend 하 는 interface 의 timeout 의 종류에 포함하는 방법을 사용하고 있다. timeout 의 종류 에는 FOREVER, NOWAIT, Timeout 이렇게 3 가지의 사용이 가능하다. pSOS 의 경 우에는 WAIT 과 NOWAIT 을 나누는 wait parameter 를 사용하고 WAIT 이라고 사 용하는 경우에 0 혹은 Timeout 값을 사용하도록 interface 를 가져가고 있다.

VRTX 와 uC/OS II 의 경우에는 NOWAIT 을 위해 accept()라는 interface 를 추가적 으로 만들어 사용하고 있다.

Interface 의 형태

Semaphore 와 Mutex 는 의미상 매우 유사하며, Mutex 는 Semaphore 의 Subset 에 해 당한다. Mutex 를 제공하는 RTOS 는 VxWorks, VRTX, uC/OS II (v2.04 이상)에서 지원 된다. VRTX 와 uC/OS 의 경우에는 Semaphore 와 Mutex 를 위해 각각의 interface 군을 사용하는 반면 VxWorks 의 경우에는 Create 용 interface 만 별도로 사 용하고 나머지 interface 는 같이 사용하는 방법을 택하고 있다.

용어의 차이

Semaphore 의 경우 VxWorks 는 Take 와 Give 를 사용하고 있다. pSOS 의 경우에는 P/V 를 사용하며, VRTX.와 uC/OS II 의 경우에는 Pend/Post 를 사용한다. Nucleus 의 경우에는 Obtain/Release 라는 용어를 사용한다.

Mutex 의 경우에도 차이를 보이는데 VxWorks 는 Semaphore 와 같은 Take/Give 를 적용하고 있고, VRTX 는 Lock/Unlock 을 사용한다.

특수 Interface

VxWorks 의 semMGiveForce()는 ownership 에 관계없이 Mutex 에 give 를 하는 기능 을 수행할 수 있다. semFlush()는 semaphore 에 pend 되어 있는 모든 task 를

(12)

unblock 시킨다.

Nucleus 의 경우 NU_Reset_Semaphore()를 사용하여, semaphore 를 초기값으로 다시 설정할 수 있다. Pending 되어 있는 task 는 resume 되어진다.

(13)

3.3 Queue

일반 (Variable-length 와 Fixed-length)

Queue 는 두 가지로 구분된다. 하나는 queue 의 message 의 크기가 일정한 Fixed- length queue 와 message 마다 크기가 다를 수 있는 variable-length queue 이다. pSOS, Nucleus 의 경우에는 두 가지 다를 지원한다. VxWorks 의 경우에는 Variable-length 만을 지원하도록 되어 있으며 VRTX 와 uC/OS II 의 경우에는 Fixed-length 만을 지 원한다. 유의해야 할 사항은 Nucleus 로서 여기서 사용되는 Variable-length 의 개념 은 VxWorks 나 pSOS 와 약간 다르게 사용된다. VxWorks 와 pSOS 의 경우에는 queue 의 최대 message 의 크기와 수를 생성시 주도록 되어 있다. RTOS 는 이 최 대치에 맞도록 memory 를 allocation 받는다. 따라서 생성시의 Message 의 최대수는 항상 보장된다. 한편 Nucleus 의 경우에는 Queue 에 사용되는 memory 를 사용자가 주고 최대 message 의 수 또한 사용자가 주기 때문에 variable-length queue mode 로 동작하는 경우에는 memory 의 한계 혹은 최대 message 의 수로서 제한되어 지게 된다. 따라서 사용자가 제공하는 최대 message 의 수가 RTOS 에 의해서는 보장되 지는 않는 개념이다. 전적인 사용자의 책임인 셈이다.

Priority or FIFO

Queue 에 pending 되는 형태에 따라 priority 와 FIFO Queue 로 나뉜다. uC/OS II 의 경우에는 Priority 만을 지원한다. 나머지 RTOS 는 priority 와 FIFO 모두를 지원하 도록 되어 있으며 이는 Queue 생성시 선택할 수 있도록 되어 있다.

QCB 의 관리

Nucleus 의 경우에는 Queue Control Block 을 사용자가 지정하도록 되어 있다. 나 머지 RTOS 의 경우에는 OS 에서 알아서 관리하여 준다.

Queue 용 Memory 관리

Nucleus 의 경우에는 Queue 에 필요한 Memory 를 사용자가 제공하도록 되어 있 다. 다른 RTOS 의 경우에는 사전에 설정된 Memory 에서 할당을 받아 사용하게 된다.

Name 의 사용

pSOS 와 Nucleus 에서는 Queue 에 이름을 부여할 수 있다. 각각 4 자와 8 자를 지

(14)

원하며 그 외의 RTOS 는 Name 을 지원하지 않고 단지 Queue ID 만을 사용한다.

Send/Post timeout 의 사용

Send/Post timeout 이란 Queue 가 full 인 경우에 추가로 send/post 하게 되는 경우에 error 를 return 하지 않고, 기다렸다 send/post 하는 blocking 기능을 말한다. 이러한 기능을 제공하는 RTOS 는 VxWorks 와 Nucleus 이다. 나머지 OS 는 error 가 return 되어 진다.

Priority Send/Post

Send/Post 시 일반과 긴급 두 가지로 나뉘어 진다. 일반은 message 를 queue 의 맨 뒤에 넣는 반면, 긴급의 경우에는 queue 의 맨 앞에 넣어주게 된다. 5 개의 RTOS 가 이와 같은 기능을 제공하나 VRTX 의 경우에는 약간 특이하다. VRTX 에는 queue 를 생성시 하나의 message 를 위한 추가 공간이 생성된다. VRTX 에서는 qjam 이라는 용어를 사용하는데, qjam 을 하게 되면 여분의 space 에 넣어주게 된 다. 물론 pend 시에는 이 message 를 제일 먼저 수신하게 된다. 차이점은 qjam 이 1 회에 한정되어 있다는 점이다. 이미 qjam 이 되어 있는 상태에서 qjam 을 다시 하면 error 를 return 하게 된다. 다른 RTOS 에서는 queue 가 full 이 될 때까지 qjam 을 할 수 있으며, send/post timeout 을 지원하는 경우 기다릴 수도 있다.

Queue 에서 Timeout 에는 3 가지를 지원한다 : Timeout, 무한대, No Timeout.

이 중에서 No Timeout, 즉 Queue 에서 메시지를 받을 수 없는 경우에 Pend 되지 않고 즉시 Return 되는 형태를 말한다. VxWorks, Nucleus 의 경우에는 NOWAIT 을 pend 하는 interface 의 timeout 의 종류에 포함하는 방법을 사용하고 있다. timeout 의 종류에는 FOREVER, NOWAIT, Timeout 이렇게 3 가지의 사용이 가능하 다. pSOS 의 경우에는 WAIT 과 NOWAIT 을 나누는 wait parameter 를 사용하고 WAIT 이라고 사용하는 경우에 0 혹은 Timeout 값을 사용하도록 interface 를 가져 가고 있다. VRTX 와 uC/OS II 의 경우에는 NOWAIT 을 위해 accept()라는 interface 를 추가적으로 사용한다.

Broadcast 기능

Broadcast 의 기능이란 Queue 에서 pend 되어 있는 모든 Task 에게 동일한 메시지를 보내는 기능을 말한다. 이를 지원하는 RTOS 는 pSOS, VRTX, Nucleus 이며 VxWorks 와 uC/OS 에서는 직접 지원을 하지 않는다. 기능상 약간의 상이점은

(15)

pSOS, VRTX 의 경우에는 pend 하는 task 가 없는 경우에는 아무런 효과가 없는 반 면에 Nucleus 의 경우에는 일반 send/post 를 하는 효과를 가지는 차이점이 있다.

용어의 차이

VxWorks, pSOS, Nucleus 의 경우에는 send/receive 를 사용하고 있다. VRTX 와 uC/OS II 의 경우, post/pend 를 사용하고 있다.

특수 interface

Nucleus 의 경우, NU_Reset_Queue()을 사용하여 Q 의 내용을 clear 하는 기능을 제 공한다. uC/OS II 에도 OSQFlush() 처럼 Q 의 내용을 clear 하는 기능을 제공한다.

(16)

3.4 Event Flag

일반

VxWorks 에서는 Event Flag 을 지원하지 않는다. 그 외의 RTOS 는 지원을 하나 pSOS 의 개념이 무척 독특하다. 자세한 내용은 아래를 참조하기 바란다. uC/OS II 의 경우, 2.05 부터 Event Flag 을 지원한다.

개념상의 차이

pSOS 의 경우에는 event flag 이 독립적이지 않고 Task 당 하나의 event flag 이 존재 한다. Event flag 에 pend 할 수 있는 task 는 그 event flag 을 소유하고 있는 task 에 한한다. 결과적으로 n-to-1 의 관계가 성립된다. 여러 개의 task 가 event flag 에 pend 될 수 있는 n-to-n 관계의 VRTX, Nucleus, uC/OS II 의 경우와는 다른 개념이 다. 이와 같은 개념의 차이로 인해, pSOS 에는 create 이나 delete 에 대한 interface 가 없다. event flag 도 별도의 ID 를 사용하지 않고 taskID 를 그대로 사용하게 된 다. 물론 pend 시에는 event flag ID 를 사용하지 않는다. 자신의 event flag 에만 pend 가 가능하기 때문이다.

(pSOS 의 base 를 가진 분을 위해), VRTX, Nucleus, uC/OS II 의 event flag 은 queue 와 마찬가지로 독립적인 object 로써 dynamic 하게 생성, 삭제 되어 진다. 여러 Task 가 event flag 에 post 할 수 있으며 또한 여러 task 가 pend 할 수 있는 구조로 되어 있다.

FCB 의 관리

Nucleus 의 경우에는 Flag Control Block 을 사용자가 지정하도록 되어 있다. 나머 지 Event Flag 을 지원하는 RTOS 에서는 OS 가 스스로 관리한다.

Name 의 사용

Nucleus 에서는 Flag 에 이름을 부여할 수 있다. 8 자를 지원한다. 그 외의 RTOS 는 Name 을 지원하지 않고 단지 Flag ID 만을 사용한다.

Consume 기능

Event flag 은 queue 와 달라서 pend 하여도 소비하는 것이 아니고 flag 을 참조하는 것으로 동작한다. Flag 은 상태를 저장한다고 생각하기 때문이다. 물론 pSOS 에서 는 이런 개념을 가지지 않고 항상 pend 후에는 event 가 clear 되도록 동작한다. 이

(17)

는 event 를 수신하는 Task 가 단 하나이기 때문에 가능한 개념으로 보여진다. 이 와 비교하여, Nucleus 와 uC/OS II 의 경우에는 pend 시 consume 을 지원하는 option 을 사용할 수 있도록 되어 있다. VRTX 의 경우에는 이러한 기능을 제공하지 않 으며 clear interface 를 사용하여야 한다.

Flag 에서도 Timeout 3 가지를 지원한다 : Timeout, 무한대, No Timeout.

이 중에서 No Timeout, 즉 Flag 에서 원하는 상태를 받지 못한 경우에 Pend 되지 않고 즉시 Return 되는 형태를 말한다. Nucleus 의 경우에는 NOWAIT 을 pend 하는 interface 의 timeout 의 종류에 포함하는 방법을 사용하고 있다. timeout 의 종류에 는 FOREVER, NOWAIT, Timeout 이렇게 3 가지의 사용이 가능하다. pSOS 의 경우 에는 WAIT 과 NOWAIT 을 나누는 flags parameter 를 사용하고 WAIT 이라고 사용 하는 경우에 0 혹은 Timeout 값을 사용하도록 interface 를 가져가고 있다.

VRTX 와 uC/OS II 의 경우에는 NOWAIT 을 위해 각각 inquiry(), accept()라는 interface 를 추가적으로 만들고 있다.

CLR 에 pend 기능

Flag 은 일반적으로 Set 되는 것을 기다리는 형태로 동작한다. uC/OS II 의 경우에 는 이와 반대로 CLR 된 상태를 기다리는 기능을 제공한다. 다른 RTOS 에서 볼 수 없는 특이한 기능이다.

Flag Clear 기능

pSOS 의 경우에는 Flag 을 Clear 할 수 없도록 되어 있다. VRTX 의 경우에는 sc_fclear()라는 interface 를 제공하고 있으며, Nucleus 의 경우에는 0 과 AND option 을 사용하여 bit 를 clear 할 수 있다. uC/OS II 의 경우에는 option 에 CLR 이라는 것을 사용하여 해당 mask 를 clear 할 수 있다.

용어의 차이

pSOS 의 경우에는 receive 와 send 개념을 사용한다. Queue 와 같다는 생각으로 보 인다. VRTX 와 uC/OS II 의 경우에는 pend/post 를 사용하며, Nucleus 의 경우에는 Retrieve 와 Set 을 사용한다.

(18)

3.5 Memory Partition

일반

Memory partition 은 memory pool 내부의 entry 크기가 동일한가 아니면 다를 수 있 는가에 따라서 Fixed-size partition 과 variable-size allocation 방식으로 나뉜다. Fixed- size 의 경우, 생성시 entry 의 크기를 지정하게 되나 variable-size 의 경우에는 allocate 시 원하는 memory 의 size 를 지정한다. 아래의 내용은 두 가지 종류의 memory pool 에 공통적으로 해당되는 사항이다.

Multiple pool 의 지원

하나의 Partition 에 필요에 따라 pool 을 추가 하여 여러 pool 이 하나의 partition 을 구성하게 되는 기능이다. 이 기능은 VxWorks 와 VRTX 에서만 지원된다.

Name 의 사용

pSOS 와 Nucleus 에서는 Memory Partition 에 이름을 부여할 수 있다. 각각 4 자와 8 자를 지원하며 그 외의 RTOS 는 Name 을 지원하지 않고 단지 ID 만을 사용한다.

Memory 용 CB 의 관리

Nucleus 의 경우에는 Memory 에 필요한 Control Block 을 사용자가 지정하도록 되 어 있다. 나머지 RTOS 에서는 OS 가 스스로 관리한다.

Delete 기능 지원

VxWorks 와 uC/OS II 의 경우에는 Partition 의 생성만 가능하고 삭제에 대한 interface 를 지원하지 않는다. pSOS, VRTX, Nucleus 의 경우에는 삭제가 가능하다.

Pend 기능

Memory Pool 에서 원하는 memory 를 allocate 할 수 없는 경우에 Queue 나 Semaphore 같이 pend 를 지원하는 기능이다. pSOS 와 Nucleus 의 경우에는 이 기능 을 지원하며, memory 가 available 할 때까지 기다리게 된다. Queue 와 마찬가지로 timeout 을 주거나, 무한대로 기다릴 수 있게 할 수 있다. pSOS 의 경우 유의해야 할 사항이 있는데. pSOS 의 malloc()은 rn_getseg()를 사용하여 구현되어 있으며, 사용되는 flag, timeout option 이 pend 되는 기능을 사용하였을 때는 malloc() 사용 시에 memory 가 없으면 task 가 pending 되는 현상이 발생할 수 있다. 이 설정은

(19)

pREPC+ Configuration Table 에서 해주도록 되어 있다.

용어의 차이

VxWorks 에서는 memory partition (variable)이라는 용어를 사용한다.

pSOS 에서는 variable-size memory 를 segment 라고 부르며 이에 대한 pool 을 memory region 이라 부른다. fixed-size memory 는 buffer 라 부르며 이 pool 은 partition 이라 부른다.

VRTX 에서는 Partition (fixed)과 Heap (variable)의 개념을 사용한다.

Nucleus 에서는 Partition Memory (fixed)와 Dynamic Memory Pool (variable)을 사용함 uC/OS II 의 경우에는 Memory Partition (fixed)을 사용한다.

(20)

3.5.1 Fixed-size Partition

지원여부

VxWorks 의 경우에는 Fixed-Size Partition 을 지원하지 않는다. Fragmentation 을 방 지하기 위해서 Allocation 시에 동일한 size 를 사용함으로써 Fixed-size Partition 의 효과를 얻을 수 있다. 그 외의 OS 에서는 memory partition 을 지원한다.

Entry 수의 제한

pSOS, Nucleus, uC/OS II 의 경우에는 32-bit 만큼의 memory 의 size 를 설정할 수 있 으므로 제한이 없다고 바도 될 것으로 생각된다. VRTX 의 경우에는 entry 의 수 가 65534 를 넘지 못하도록 제한이 되어있다.

Partition block 의 크기의 제한

VRTX, Nucleus, uC/OS II 의 경우에는 4 byte 단위로 지원을 하도록 되어 있다. 이 말은 Partition 생성시 8 byte 씩은 되나 9 byte 씩은 지원하지 않는다는 이야기 다. 32-bit 를 대부분 기본 CPU 로 하고 있으므로, 일리가 있다고 본다. pSOS 의 경우에는 특이한 제한이 있는데 2 의 제곱단위로 만들 수 있으며 최소의 단위는 16 byte 로 되어 있다. 이것은 16, 32, 64, 128, 256 단위의 partition 만을 만들 수 있 다는 의미이며 Size 가 커지면서 내부에서 낭비되는 memory 의 양이 많아지는 현 상이 발생하게 된다.

(21)

3.5.2 Variable-size Allocation

지원여부

uC/OS II 의 경우에는 Variable-Size Partition 을 지원하지 않는다. VxWorks, pSOS, VRTX, Nucleus 는 지원한다.

Entry 수의 제한

VxWorks, VRTX, Nucleus 의 경우에는 32-bit 만큼의 memory 의 size 를 설정할 수 있으므로 제한이 없다고 볼 수 있다. pSOS 의 경우에는 32767 만큼의 entry 만을 사용할 수 있는 제한이 있다.

최소 Block Size

Memory 를 효과적으로 관리하기 위하여 memory pool 을 block 을 잘라서 관리한 다. pSOS, VRTX 의 경우에는 Block 의 size 를 사용자가 조정할 수 있으며, block size 를 크게 해주면 overhead 가 줄어들고 속도가 빨라지는 반면 memory 를 낭비 하게 되고, block size 를 작게 해주면 좀 더 세밀한 allocation 이 가능하여 memory 의 낭비를 줄일 수 있지만 overhead 가 늘어나게 되는 단점이 있다. pSOS 의 경우 에는 2 의 제곱을 사용할 수 있으며 최소는 16 byte 이다. VRTX 의 경우에도 2 의 제곱만을 사용할 수 있으며 최소는 8 byte 단위로 나눌 수 있다. (VxWorks 와 Nucleus 의 경우에는 사용자 option 이 없으며 default 로 사용하는 memory block size 에 대한 정보를 찾을 수 없었다.)

malloc/free 지원

ANSI interface 인 malloc 과 free 를 지원하는 OS 는 VxWorks, pSOS, VRTX 이며, Nucleus 에서는 malloc/free 를 지원하지 않는다. uC/OS II 에서는 dynamic memory allocation 자체를 지원하지 않는다. 필요한 경우에, 사용자가 직접 만들어 사용하 여야 한다.

malloc/free 용 memory pool 명칭

malloc 에 사용되는 memory pool 의 명칭이 OS 에 따라 각각 다르게 사용된 다. VxWorks 의 경우에는 System Partition 이라 부르며, pSOS 의 경우에는 Special Region 0 이란 용어를 사용한다. VRTX 의 경우에는 Heap ID 0 번을 사용하는 VRTXsa Workspace Heap 을 이용하게 된다.

(22)

Appendix A. 문서정보 A.1 문서이력

문서목적

5 가지 RTOS 의 Interface 를 비교함으로써 RTOS 에 대한 이해를 돕는다.

작성자

제임스 /

james@novonetworks.com

도움 주신분

강 병주, 두 영호, 김 길남, 신 병주

그 외 크고 작은 도움을 주신분 들께 감사 드립니다.

작성이력

Upgrade 1.1 : 2004-11-08 최초작성 : 2001-6