임베디드 소프트웨어 (2) - 펑션스케줄링 구조, RTOS 구조

 

앞에 이어서 임베디드 소프트웨어의 남은 두 종류를 알아보겠습니다.

 

 

[평션스케줄링 구조]

 

펑션스케줄링이라고 불리는 이 구조는 이전과 다른 약간 복잡한 구조를 보여줍니다. 이 구조에서 인터럽트 루틴은 함수 포인터를 메인 함수가 호출할 수 있도록 함수 포인터의 큐에다 넣습니다. 메인 함수는 단지 큐로부터 포인터를 읽어서 함수를 실행하죠.

 

이 구조의 장점은 인터럽트 루틴이 발생하는 순서대로만 메인 함수가 함수들을 호출해야 할 필요는 없다는 것에 있습니다. 사용하려는 목적에 맞는 어떠한 우선순위 정책으로도 함수들을 호출할 수 있습니다. 빠른 응답을 필요로 하는 태스크 코드의 함수들은 더 일찍 수행될 수 있고요. 함수 포인터들의 큐를 다루는 루틴을 현명하게 작성해서 이러한 모든 것들을 수행할 수 있습니다.

 

이런 구조에서 높은 우선 순위를 갖는 태스크 코드 함수가 수행될 때까지 걸리는 최악의 대기 시간은 태스크 코드 함수 중에서 제일 긴 함수의 수행 시간과 같습니다. 조금 더해보자면 인터럽트가 발생했을 때 인터럽트 루틴의 수행 시간도 더해야 하죠. 가장 긴 태스크 코드가 막 시작했을 때, 가장 높은 우선순위의 장치를 위한 인터럽트가 발생할 경우에는, 이와 같은 최악의 경우가 됩니다. 이전에 다루었듯이 인터럽트 라운드로빈 방식은 인터럽트가 걸린 모든 태스크 코드의 함수들의 수행 시간의 합이 응답 시간이라서 이 구조는 인터럽트 라운드 로빈 방식보다 응답이 빠릅니다. 이렇게 더 빠른 응답은 복잡하다는 것도 있지만 낮은 우선순위의 태스크 코드 함수의 응답이 나빠진다는 사실과 트레이드오프 관계입니다. 인터럽트 라운드로빈 구조에서는 모든 태스크 코드는 메인 함수가 루프를 돌 때마다 매번 실행될 기회를 갖습니다. 펑션스케줄링 구조에서는 인터럽트 루틴이 높은 우선순위를 가진 함수가 마이크로프로세서의 가능한 모든 시간을 소모하도록 큐를 스케줄링한다면, 낮은 우선순위를 갖는 함수는 실행조차 되지 못하게 됩니다.

 

펑션스케줄링 구조는 높은 우선순위의 태스크 코드에 대해 최악의 경우의 응답 시간을 줄이는 이점은 분명히 있습니다. 부인할 수 없는 장점이지만 낮은 우선순위의 함수들 가운데 하나라도 수행되는데 오랜 시간이 걸린다면 높은 우선순위 함수의 응답 시간에 영향을 주기 때문에 아직도 완벽한 구조라고 할 수는 없습니다. 완벽이라는 단어는 아무 곳에나 붙여서는 안 되는 것이죠. 때때로 긴 함수를 작은 부분으로 나누어 다시 작성해서 각 부분이 다음 부분을 가리키도록 함수 큐에 저장하는 방법으로 해결하기도 하지만 이렇게 된 경우 코드가 상당히 복잡하게 됩니다. 결국 이어서 소개할 RTOS 구조 만이 해결을 가능하게 합니다.

 

 

[RTOS 구조]

 

사실상 이 카테고리는 이 구조에 대한 얘기로 가득 채워질 가능성이 높습니다. 이 구조에서는 여태까지 다루었던 다른 구조들처럼, 인터럽트 루틴이 가장 급한 일을 처리합니다. 그리고 나서는 태스크 코드에게 수행해야 할 일이 있다고 시그널을 보냅니다. 그래서 이 구조가 뭐가 다르냐고요? 다음과 같습니다.

 

• 인터럽트 루틴과 태스크 코드 사이에서 필요한 시그널의 교환은 RTOS가 처리를 해줍니다. 이러한 것을 위해 따로 공유 변수를 사용할 필요가 없습니다.
• 코드에 있는 루프는 다음에 어떤 함수가 수행되어야 하는지에 대해서는 아무런 정보를 가지고 있지 않습니다. RTOS 내부에 있는 코드가 어떤 태스크 코드 함수가 수행되어야 하는지를 결정합니다. RTOS는 다양한 태스크 코드 서브루틴에 대한 정보를 알고 있는데 어떤 순간에 가장 긴급한 서브루틴을 결정해서 수행시킵니다.
• RTOS는 다른 서브루틴을 수행하기 위해 현재 처리 중인 서브루틴을 일시 정지 시킬 수 있습니다.

 

다른 점 중에서 앞선 두 개는 프로그램을 편하게 하기 위한 것이고, 마지막은 RTOS의 본질적인 면이라고 생각하면 편합니다. RTOS 구조를 사용하는 시스템은 인터럽트 루틴의 응답 우선 순위를우선순위를 조정할 뿐만 아니라 태스크 코드의 응답도 조정할 수 있습니다. 만약 a가 가장 높은 우선순위를 가진 태스크 코드라면 인터럽트 루틴이 시그널 X를 설정했을 때 RTOS는 a를 바로 수행시킵니다. 만약 b가 현재 수행 중이라면, RTOS는 b 수행을 일시정지하고 a를 바로 실행시킵니다. 따라서 가장 높은 우선순위를 가진 태스크 코드에 대한 최악의 지연 시간은 없다고 봐야 마땅합니다. 정확히 말하자면 인터럽트 수행 시간은 더해지긴 하지만요.

 

이러한 스케줄링 방법의 부수적인 효과는 심지어 코드를 수정하는 경우에도, 상대적으로 일정한 시스템 응답을 얻을 수 있다는 것에 있습니다. 라운드로빈 구조와 펑션큐스케줄링 구조에서 태스크 코드 함수를 위한 응답 시간은 다양한 태스크 코드의 서브루틴, 심지어는 더 낮은 우선순위의 서브루틴의 길이에 따라 달라집니다. 만약 어떤 서브루틴을 수정했을 경우 시스템 전체에 걸쳐 응답 시간을 변경시키는 결과를 초래하기도 하지요. 하지만 RTOS 구조에서는 낮은 우선 순위 함수를 수정하는 경우는 일반적으로 높은 우선순위 함수의 응답에 영향을 끼치지 않습니다.

 

또 다른 RTOS 구조의 좋은 점은 구입할 수 있는 RTOS가 정말 다양하게 있다는 것입니다. RTOS를 구입함으로써, 어떤 시스템의 응답 문제에 대해서 즉각적인 해결책을 얻을 수 있기 때문이지요. 역시 돈이 최고 긴 합니다. 또한 유용한 디버깅 툴도 얻을 수 있고요.

 

RTOS 구조도 단점은 있습니다. 물론 값을 지불해야 한다는 것을 빼고 RTOS 자체가 시스템의 프로세스 시간을 사용한다는 것입니다. 약간의 프로세스 시간을 희생해서 더 나은 수준의 응답을 얻을 수 있다고 이해하는 게 정답에 가깝겠죠.

 

RTOS에 대해서는 계속해서 다룰겁니다. 특히 RTOS가 무엇을 하고, 어떻게 효과적으로 사용되며, 단점을 어떻게 피해 가는지까지 다뤄볼예정입니다.

 

 

[그래서 소프트웨어 구조는 어떻게 선택하나]

 

설계하려는 시스템에 맞는 구조를 선택하는 방법에 대해서 제안해보겠습니다.

 

• 설계하려는 시스템의 응답 조건에 맞는 가장 간단한 구조를 선택해야 함. 필요 이상으로 복잡한 구조를 선택하지 않더라도 이미 임베디드 시스템 소프트웨어를 작성하는 것은 정말 충분히 복잡한 일임에 틀림이 없음. but 새로운 버전을 위한 조건이 기존의 것보다 엄격할 것이라는 대는 의심의 여지가 없음.
• 만약 설계하려는 시스템이 RTOS를 사용해야 할 필요가 있는 응답 조건을 가지고 있다면, RTOS 구조를 사용하는 방향으로 결정해야 함. 대부분의 상용 RTOS는 시스템을 테스트하고 디버깅을 쉽게 할 수 있는 유용한 툴들을 같이 제공함.
• 설계하려는 시스템에 필요하다면 혼합 형태를 만들어 낼 수도 있음. RTOS를 사용하고 있더라도 빠른 응답이 필요 없는 하드웨어를 다루기 위해 루프를 돌면서 값을 읽는 낮은 우선순위의 태스크 코드를 가질 수도 있음. 마찬가지로, 인터럽트 라운드로빈 구조에서 느린 응답의 하드웨어를 다루기 위해 인터럽트 루틴에 의한 플래그 값을 읽는 대신에 직접 메인 루프에서 정기적으로 하드웨어 값을 읽을 수도 있음
• 일반적으로 하려는 일에 맞는 가장 간단한 구조를 택하는 것이 좋음

 

참고)

 

임베디드 소프트웨어 (1) - 라운드로빈 구조, 인터럽트 라운드로빈 구조