Drone's DIYer

실시간 시스템(real time system)은 임의의 정보가 시스템 내/외부에서 이벤트 혹은 인터럽트(interrupt)의 형태로 시스템에 입력되었을 때 주어진 시간 안에 작업이 완료되어 결과가 주어져야 하는 시스템입니다. 즉, 이벤트 발생과 처리가 실시간으로 이루어지는 시스템입니다. 물론 CPU의 처리 속도를 증가시킬 수도 있지만 속도는 느리더라도 이벤트 처리 시간을 보장할 수 있도록 하여야 한다는 의미입니다.

RTOS(Real Time Operating System) 없이 펌웨어를 제작하여도 모든 작업을 할 수는 있습니다. 예전의 시스템에서 펌웨어(firmware)는 비교적 간단해서 OS의 개념을 적용하지 않고 순차적인 프로그램만으로 작성했어도 그리 문제가 되지 않았습니다. 하지만 최근에 점점 더 소형기기에 들어가는 기능이 다양해지고 Windows OS처럼 이벤트가 수ms 정도에 처리되어도 가능한 상황과 달리, 임베디드 시스템(embedded system)에서는 훨씬 빠른 응답을 요구하여 순차적인 프로그래밍 방식으로는 기능을 구현하기에 어려워졌고 시간도 많이 걸려 다음의 장점으로 여러개의 태스크(task)로 분할하여 개발할 필요가 있다는 것입니다. 왜냐면 여러가지 일을 할 수 있는 순차적인 프로그램 방법으로 구현하면 프로그램의 복잡도가 일의 갯수의 승수에 비례하기 때문입니다.

1. 코드의 개발, 수정, 유지, 보수가 보다 용이합니다.

2. 이벤트에 대해 보다 신속하게 응답할 수 있습니다. - 인터럽트가 발생하면, 진행 중인 태스크 대신 인터럽트를 처리할 태스크를 우선적으로 실행할 수 있습니다.

3. 시스템의 신뢰도와 성능을 높일 수 있습니다.

한편 우선 순위 방식에는 2가지가 있는데, 우선 순위가 높은 태스크가 우선 순위가 낮은 태스크를 잠시 멈추게 하고 프로세서를 차지할 수 있는 권한이 부여되면 최근 대부분 OS가 그렇듯 선점형 우선순위(Preemptive)가 됩니다. 반면에 우선 순위가 높다 하더라도 우선 순위가 낮은 태스크가 완료할 때까지 기다려 주는 방식을 Windows 95이전의 OS와 같은 비선점형 우선순위(Non-preemptive)라 부릅니다.

임베디드 시스템에서는 주로 선점형을 사용하는데, 우선 순위에 따라 프로세서의 사용 권한을 조정하는 것을 스케줄링(Scheduling)라고 부릅니다. 이와 같이 진행 중인 태스크가 바뀌게 되면 컨텍스트(Context)라고 불리는 기존의 태스크에 대한 정보를 저장하고 새로운 태스크를 불러오는 동작을 해야 하는데 이를 컨텍스트 스위칭(context switching)이라고 합니다. 또한 진행 중인 태스크들의 각종 정보를 태스크 컨트롤 블럭(TCB: Task control block)이라고 부릅니다. 다음은 선점형 OS에서 사용하는 스케줄링 방식입니다.

1. Priority Scheduling Algorithm

2. Round-Robin Scheduling Algorithm

이처럼 예전에는 하드웨어 성능과 크기의 제약으로 OS 없이 단순한 기능만 수행 가능했던 것이 하드웨어 성능의 향상으로 다양한 일이 요구되었습니다. 이에 RTOS라는 OS 개념을 도입하여 각각의 태스크에 대한 스케줄링으로 자원을 효율적으로 사용할 수 있게 하고 복잡한 일들을 태스크로 나눔으로써 일을 단순화 시킬 수 있다는 것입니다. 뿐만 아니라 다음과 같은 까다로운 문제가 발생하는데, 이들 문제를 직접해결하기 보다는 멀티태스킹(multi-tasking; 엄밀하게 multi-threading) OS를 도입하는 것이 훨씬 효과적이라는 것입니다. 근래에는 멀티태스킹 뿐 아니라 Network, File System, GUI도 구현하고 있습니다.

1. 태스크간 경쟁의 관리

2. 데드락(deadlock)

3. 우선 순위 역전(priority inversion)

4. 재진입 문제(reentrancy)

5. 태스크간 통신

※ 일반적인 OS vs. RTOS

• 효율성 / 시간 제약성 : 일반 OS 경우에 태스크들 사이에 효율성을 유지하려고 하지만 real-time OS에서는 태스크에 시간 제약성이 존재하고 이런 시간 제약성 때문에 효율성을 무시하는 경우가 발생하며 효율성은 고려하지 않습니다.

• 공평성 / 우선순위 : 일반 OS 경우 여러 명의 사용자가 쓰는 경우에는 각 사용자들이 실행하는 프로그램이 태스크로서 수행이 되고 대개의 경우에는 각 태스크가 공평성을 유지하려고 한다. 그러나 real-time OS에서 태스크는 대개 우선순위가 차이가 있도록 하며 이때 태스크 사이의 공평성은 고려하지 않습니다.

결론적으로 RTOS는 시간의 정확성을 보장하는 멀티태스킹 호출과 인터럽트에 대한 반응시간의 최대값을 보장할 수 있고 실행시간의 편차가 작아야 하는데 즉, 작업의 소요시간을 예측할 수 있어야 합니다. 우선순위가 높은 일이 우선적으로 자원을 분배하여 시간제한 내에 끝날 수 있도록 해야 합니다.

1. 다수의 작업에 우선 순위를 두어 멀티태스킹을 지원합니다.

2. 짧은 interrupt lattency - interrupt latency는 인터럽트가 걸려서 인터럽트 핸들러에 도착하기까지의 시간이며 이벤트에 의한 반응 속도가 빠릅니다.

3. 적은 용량의 kernel 사용 - 작고 유연한 구조(10 ~ 50 KB 수준)

임베디드(Embedded)나 펌웨어 궁극적으로는 둘다 작은 시스템 내에 하드웨어 제어를 위해 EEPROM 등에 기록되는 일종의 프로그램입니다. 거의 같다라고 봐도 무방합니다. 하지만 근래 들어서 시스템의 복잡화로 인해 기존의 펌웨어를 제작할 때 사용되는 프로그래밍 방식 '슈퍼루프 방식'은 프로그래머의 체계적인 프로그램 설계와 짜임세 있는 구성이 프로그래머를 피곤하게 할 만큼 복잡하게 되었습니다.

이에 대한 대안으로서 나온 것이 RTOS(Real Time OS)라는 것인데 ROM에 기록되는 펌웨어 중에서도 특히 이런 RTOS를 이용한 것을 임베디드(내장형 시스템)라 칭하는 경우가 많습니다. RTOS를 사용하게 되면 ROM에 기록되어야 할 펌웨어의 크기가 커지고, 시스템 오버해드라 하여 불필요한 부하를 가져다 주게 됩니다. 하지만, 펌웨어 개발의 융통성과, 안정성, 정확성을 고려할 때 펌웨어의 크기나 시스템 오버해드는 충분이 무시할 수 있는 요소가 된다는 것입니다.

대표적인 RTOS인 ChibiOS

RTOS를 이용한 임베디드 시스템은 꼭 ARM같이 거대한 프로세서에만 사용되는 것은 아닙니다. 상당히 유명한 uCOS-II경우 구식 8051부터 Intel 32bit까지 다양한 플랫폼을 지원합니다. 8051계열에도 얼마든지 임베디드 시스템을 펌웨어로 올릴 수 있습니다.

펌웨어는 일반적으로 롬(ROM)에 저장된 하드웨어를 제어하는 마이크로 프로그램을 의미합니다. 프로그램이라는 관점에서는 소프트웨어와 동일하지만 하드웨어와 밀접한 관계를 가지고 있다는 점에서 일반 응용 소프트웨어와 구분되어 펌웨어는 소프트웨어와 하드웨어의 특성을 모두 가지고 있다고 할 수 있습니다.

예를 들어 어떤 기능을 발휘하는 하드웨어를 만든다고 할 때, 그것을 제어하는 모든 회로를 하드웨어로만 만들면, 그 구조도 대단히 복잡해지고 심지어는 논리적인 표현을 하기가 어려운 부분도 발생합니다. 이런 경우 상당부분을 소프트웨어로 대체하되 그 소프트웨어가 저장된 기억장치를 하드웨어의 제어회로 중의 중심부분으로 구성하면, 매우 간단하면서도 적은 비용으로 문제를 해결할 수 있게 됩니다. 이렇게 만든 하드웨어적인 소프트웨어를 펌웨어라 합니다.

이렇게 할 경우 하드웨어의 입장에서는 별도의 논리회로를 가진 것이 아니기 때문에 소프트웨어적인 특성을 가지고 있지만, 소프트웨어 입장에서는 마이크로 프로그램이 하드웨어를 제어하기 때문에 하드웨어적인 특성을 가진다고 설명할 수 있습니다.

소프트웨어의 기능을 펌웨어로 변경할 수 있으면 속도가 현저하게 증대되어 고속 처리가 필요한 프로그램은 펌웨어로 만들어 사용하기도 합니다. 또한 하드웨어의 기능을 펌웨어로 변경하면 속도는 느려지지만, 그 기능을 위한 논리회로를 설계하여 사용하는 것보다 저렴하고, 편리하게 구현하여 사용할 수 있는 장점을 가지기도 한다는 것입니다.