VxWorks, pSOS, VRTXsa, Nucleus, uC/OS II의 Interfac..

	VxWorks, pSOS, VRTXsa, Nucleus, uC/OS II의 Interface 비교
	본 자료는 RTOS의 차이점을 이야기 함으로써 하나의 RTOS를 접하고 다른 RTOS의 이해에 도움이 되고자 하는 취지에서 작성하였다.  따라서 본 글의 독자는 적어도 하나의 Thread방식의 RTOS를 접하여 도움이 될 것 같다는 생각이 든다.  혹시 본인이 그렇지 않다면 하나의 RTOS를 선택하여 깊게 공부해봄도 바람직 할 것으로 보인다.   위의 5가지 OS는 모두 Thread 방식으로 동작하나 약간의 차이점을 보인다. 여기서는 RTOS의 Kernel부분의 interface부분의 차이점에 대해서 다루고 있다.  본 자료의 내용은 일반적인 경우에 대한 내용을 토대로 하고 있으며 미세한 내용은 각 RTOS의 문서의 참조가 필요할 것으로 사료된다.     [ Task ]   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의 경우에는 길이의 제한이 없으나 지원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의 경우에는 Task가 생성된 후에 suspend되는 형태로 되어있어 sc_tresume()이 VxWorks의 taskActivate()의 기능을 동시에 수행하고 있다.   Argument Passing Task생성시에 생성 Task에서 생성되는 Task에게 Data를 보내기 위하여 Argument를 지원한다.  Argument는 RTOS마다 독특한 형태를 취하고 있어 공통점을 찾기 어렵다.  VxWorks의 경우에는 10개의 integer argument를 사용하도록 되어 있다.  pSOS의 경우에는 4개를 사용할 수 있다.  VRTX의 경우에는 char *paddr과 unsigned long psize의 형태를 띈 하나의 parameter block을 보낼 수 있다.  Nucleus의 경우에는 argc와 argv형태를 사용하며 uC/OS II의 경우에는 3개의 parameter를 보낼 수 있다.     [ 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 Sempahore에 pending되는 형태에 따라 priority와 FIFO로 나뉜다.  uC/OS의 경우에만 유일하게 Priority만을 지원한다.  나머지 RTOS는 priority와 FIFO모두를 지원하도록 되어 있으며 이는 create 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와 pSOS는 현재 확인 중이다.)   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을 사용한다.  pSOS 3와 uC/OS II 2.04는 확인중이다.     [ 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로 나뉜다.  uC/OS의 경우에만 유일하게 Priority만을 지원한다.  나머지 RTOS는 priority와 FIFO모두를 지원하도록 되어 있으며 이는 create interface시 선택할 수 있도록 되어 있다.   QCB의 관리 Nucleus의 경우에는 Queue Control Block을 사용자가 지정하도록 되어 있다.   Queue용 Memory 관리 Nucleus의 경우에는 Queue에 필요한 Memory를 사용자가 제공하도록 되어 있다.  다른 RTOS의 경우에는 사전에 설정된 Memory에서 할당을 받아 사용하게 된다.   Name의 사용 pSOS와 Nucleus에서는 Queue에 이름을 부여할 수 있다.  각각 4자와 8자를 지원하며 그 외의 RTOS는 Name을 지원하지 않고 단지 Queue ID만을 사용한다.   Send/Post timeout의 사용 Send/Post timeout이란 Queue가 full인 경우에 추가로 send/post하게 되는 경우네 error를 return하지 않고, 기다렸다 send/post하는 기능을 말한다.  이러한 기능을 제공하는 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이 되어 있는 상태에서 qjam을 다시하면 error를 처리한다는 점이 다른 RTOS와 다른 점이다.  그 외의 RTOS에서는 queue전체가 full인 경우에는 error로 처리되거나 sending에서 기다리게 된다.   Timeout중 No Wait기능 형태 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에서는 직접 지원을 하지 않는다.  기능상 약간의 상이점은 pSOS, VRTX의 경우에는 pend하는 task가 없는 경우에는 아무런 효과가 없는 반면에 Nucleus의 경우에는 일반 send/post를 하는 효과를 가지는 차이점이 있다.   용어의 차이 VxWorks, pSOS, Nucleus의 경우에는 send/receive를 사용하고 있다.  VRTX와 uC/OS II의 경우, post/pend를 사용하고 있다.     [ 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을 사용자가 지정하도록 되어 있다.   Name의 사용 Nucleus에서는Flag에 이름을 부여할 수 있다.  8자를 지원한다.   Consume기능 Event flag은 queue와 달라서 pend하여도 소비하는 것이 아니고 flag을 참조하는 것으로 동작한다. Flag은 상태를 저장한다고 생각하기 때문이다.  물론 pSOS에서는 이런 개념을 가지지 않고 항상 pend후에는 event가 clear되도록 동작한다.  이는 event를 수신하는 Task가 단 하나이기 때문에 가능한 개념일지도 모르겠다.  이와 비교하여, Nucleus와 uC/OS II의 경우에는 pend시 consume을 지원하는 option을 사용할 수 있도록 되어 있다.  VRTX의 경우에는 이러한 기능을 제공하지 않으며 clear interface를 사용하여야 한다.   Timeout중 No Wait기능 형태 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에서 볼 수 없는 특이한 기능이다.  하지만, 이러한 기능이 application을 작성하는 데 도움이 될른지는 의문이다.   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을 사용한다.