RTOS를 이용한 기본적인 임베디드 시스템 설계 - 개요

 

그동안 다수의 RTOS가 제공하는 다양한 기능과 적절한 사용 그리고 각 기능들과 관련된 다양한 함정에 대해서 말해왔습니다. 이제는 모두 묶어서 어떻게 효울적으로 임베디드 시스템 소프트웨어를 설계하는지에 대해서 얘기를 이어나가려고 합니다.

 

혹 내용을 혼동할 수 있으니 OS 서비스에 대한 요약을 복습부터 해보겠습니다.

 

 

[OS 서비스 살펴보기 총정리]

 

- 태스크는 동작을 제어하거나 데이터를 공유하기 위해서 서로 통신할 수 있어야 함. 대부분의 알토스들은 이런 목적을 위해서 메시지 큐, 메일박스, 파이프 등의 서비스 조합을 제공함. 이런 서비스들의 특정한 성질들은 RTOS 마다 다름. 사용하는 것의 제공 내역을 알기위해서는 메뉴얼을 읽어봐야함.

 

- 버퍼에 대한 포인터를 태스크에서 태스크 큐나 파이프, 메일박스로 보내는 것은 데이터 블록을 보내기 위해나 일반적인 방법임.

 

- 대부분의 RTOS들은 주기적으로 인터럽트를 발생시켜서 모든 알토스 다이밍 서비스가 사용할 수 있도록 하는 심장박동 타이머를 가지고 있음. 심작박동 타이머 인터럽트들 사이의 간격은 시스템 틱이라고 부름. 대부분의 일반적인 RTOS의 타이밍 서비스는 다음과 같음.

 

1. 태스크는 미리 정한 개수의 시스템 틱 만큼 스스로 대기 상태로 될 수 있음.

2. 태스크는 세마포어, 큐 등을 얼마의 시스템 틱 동안 기다릴지를 제한할 수 있음.

3. 프로그램은 미리 정한 개수의 시스템 틱 후에 특정한 함수를 호출하도록 RTOS에게 알려줄 수 있음.

 

- 이벤트는 태스크들이 서로 신호를 보낼 수 있는 1비트 플래그임. 이벤트는 그룹형태로 될 수 있고, 태스크는 그룹안에 있는 이벤트들의 조합을 기다릴 수 있음.

 

- 많은 알토스들이 표준적인 malloc과 free 함수들을 제공하지만, 소프트웨어 엔지니어들은 그들 함수들이 느리고 수행시간이 예측 가능하지 않기 때문에 사용하는 것을 자제해야 함. 대신에 고정된 크기의 버퍼들로 되어 있는 메모리 풀 기반의 메모리 할당을 사용하는 것이 일반적임.

 

- RTOS에 있는 인터럽트 루틴들은 반드시 두 가지 규칙을 준수해야함

 

1. 인터럽트 루티은 대기 상태로 들어갈 수 있는 알토스 함수를 호출해서는 안됨.

2. 인터럽트 루틴은 RTOS가 인터럽트 루틴이 수행되고 있다는 정보를 알고 있지 않는 한, 어떤 종류의 RTOS 함수를 호출해서는 안 됨. RTOS들은 인터럽트 루틴이 수행 중이라는 것을 여러 다양한 방법을 이용해서 알 수 있음.

 

 

 

다시 본론으로 돌아옵시다. 사용하려는 시스템이 RTOS를 포함한다고 가정할게요. 다양한 소프트웨어 구조에 대해서 다뤘었는데 우선 어떤 소프트웨어가 목적에 적합한지 결정해야 한다고 한 것 기억하실겁니다. 그리고 왜 알토스가 대부분의 상황에서 최적화 되는지도요. 어떤 이유에서든 알토스를 선택했다면 효과적으로 세팅하고 사용하는데 큰 도움이 될 겁니다.

 

임베디드 시스템 소프트웨어 설계는 규칙만큼이나 많은 예와가 따르기 때문에 노력이 필요하다는 것을 알게 될 겁니다. 비록 대부분 앞으로 다룰 내용에서의 권고가 유효하긴 하지만 설계는 과학에 예술을 얹어 올리는 작업이죠. 꽤 많은 시스템이 어떤 식으로든 규칙을 깨부수기 마련입니다.

 

 

[전체적으로 먼저 알아보자]

 

일단 설계에 대한 것을 미뤄두고 얘기해봅시다. 데스크톱 응용 프로그램의 명세서를 만드는 것보다 실시간 시스템의 명세서를 만드는 것이 훨씬 더 어려운 일입니다. 시스템이 무엇을 해야하지? 라는 질문에 답에 명세서는 얼마나 빨리 그것을 해야하는거지? 라는 질문에도 답을 해야만 하니까요. 가령 무선 바코드 스캐너를 단순히 바코드 데이터를 전파에 실어 금전 출납기에 보낸다고 명세서를 작성해서는 안됩니다. 이렇게 되면 바코드가 제대로 읽혔다는 소리를 듣기 위해서 오랫동안 기다려야 하는 상황이 발생할 수도 있고 그러면 직원이 일을 제대로 하지 못해서 계산하려는 손님들은 길게 늘어서게 될 겁니다. 같은 이유로 원자로의 온도가 같지 않을 때 시스템은 반응을 보여야 한다 는 식으로 명세서를 작성하는 것은 충분하지 않습니다. 시스템이 생각을 하는 동안 원자로는 녹아 내리고 있을겁니다.

 

추가적으로 프로그래머는 각각의 타이밍이 얼마나 중요한지를 알아야만 합니다. 무선 바코드 스캐너가 99퍼센트 동안 제대로 응답하고 나머지 동안 약간 느려지는 거라면 만족할만합니다. 누구든 백프로 모든 시간 동안 좋은 시스템 응답을 얻고 싶겠지만, 느린 응답의 결과가 큰 문제를 초래하지 않는다면 인간을 초월하느 노력을 들여서 얻어낼 만큼의 가치는 없다고 봅니다. 다른 편으로 원자로 문제에서는 전체 시간의 1퍼센트, 0.5퍼센트라도 빠른 응답에 실패하는 경우는 절대로 허용되지 않습니다. 원자로 시스템처럼 절대적인 제한시간을 가진 시스템들은 하드리얼타임시스템이라고 부릅니다. 반대로 좋은 응답을 원하지만 제한시간에서 약간의여유를 허용하는 것을 소프트리얼타임시스템이라고 부르고요. 균형을 위해서 대부분의 조언은 두 시스템 모두에 적용됩니다. 하드리얼타임시스템은 후에 또 다뤄보도록 할게요.

 

설계를 효율적으로 하기 위해서는 하드웨어에 대해서도 알아야만 합니다. 시스템이 시리얼 포트를 통해 1초 동안 약 천개의 문자인 9600비트를 받는다고 생각해보면 받은 각 문자들이 인터럽트를 발생시킨다고 했을 때 매 초마다 1000번 실행되는 시리얼 포트 인터럽트 루틴을 수행시킬 수 있는 소프트웨어 설계를 해야합니다. 다른 방법으로 시리얼 포트 하드웨어가 DMA 채널을 이용해서 받은 문자들을 메모리에 전송하면 시스템은 더 이상 매번 도착하는 문자들에 대해서 신경쓰지 않아도 되고 결국 인터럽트 루틴이나 그로부터 발생할 수 있는 문제들로부터 자유로워질 수 있습니다.

 

또한, 프로그래머는 사용하는 마이크로프로세서의 속도에 대한 감각을 가지고 있어야하는데요. 시스템 설계를 제대로 하러면 어떤 계산이 다른 제한시간에 영향을 미칠정도로 시간이 오래 걸리는지를 필수적으로 알아야 한다는 것이죠. 우리의 마이크로프로세서가 시리얼 포트 인터럽트 루틴을 초당 1000번 수행할 수 있고 더해서 다른 작업을 처리할 여분이 있는가 물어보는 것은 중요한 질문입니다. 불행하게도 경험과 실습만이 답이라는 슬픈 소식을 알려드려야겠지만요.

 

아마도 대부분의 프로그래머들은 임베디드 시스템 소프트웨어를 설계하는데 일반적인 소프트웨어 기술들을 사용할 것입니다. 구조화, 모듈화, 캡슐화, 유지와 보수 등에 대한 고려는 애플리케이션의 세계나 임베디드의 세계나 똑같이 중요합니다. 이런 고려들에 더해서 계속 이어나갈 내용들 역시나 사용해야합니다.

 

마지막으로 임베디드 시스템용이 아니든 사용할 특정한 설계 도구나 방법론에도 똑같이 적용됩니다. 이런 도구들은 일반 응용 소프트웨어 설계 때와 마찬가지로 임베디드 소프트웨어 설계에서도 같은 서비스를 제공할 수 있기 때문에 유용합니다만 최고의 도구를 사용한다고 해도 형편없는 설계가 나올 가능성이 있듯이 어떤 도구도 임베디드 설계에 대해 최고의 품질을 보장해주지는 못합니다. 설계의 품질은 설계자의 재능과 고심에 달려있죠. 그러므로 최고의 툴과 방법론을 사용한다고 해도, 여러 내용들과 연계해서 사용해야만 합니다.

 

임베디드 시스템을 디버깅하고 테스트하는 것은 매우 어려운 기술 중의 하나입니다. 임베디드의 세계에서는 디버깅과 태스크를 고려해서 설계하는 것이 중요합니다. 이것도 후에 다룰 때까지 잠시만 기다려주세요.