RTOS 틱에 대한 6가지 오해

본 기사는 RTOS 전문가인 Jean J. Labrosse가 작성하였습니다.

 

대부분의 RTOS는 10Hz에서 1000Hz 구간 중에 선택되는 특정 속도(Tick Rate라고 함)로 CPU를 인터럽트하여 우선순위가 높은 작업부터 처리하도록 하는, 하드웨어 타이머에서 제공하는 시간 소스를 구비하고 있습니다. 시간을 동기화하기 위한 시간 소스로는 1000Hz를 가장 일반적으로 사용합니다. 이러한 전용 RTOS 타이머를 클럭 틱, 시스템 틱 또는 RTOS 틱이라고 합니다. Tick Rate가 높을수록 RTOS가 시스템에 부과하게 되는 오버헤드가 높아집니다.

이 시간 소스는 일정 시간 동안 작업을 지연(예: 절전, 수면 모드)하고, 이벤트 발생 대기 작업에 따라 호출되는 API에 대한 타임아웃 제공하기 위해 사용됩니다. Tick Rate가 높을수록 (특정 지점까지) 시간 지연과 타임아웃의 해상도가 향상됩니다. 예를 들어, 작업은 이더넷 패킷이 도착할 때까지 대기하도록 결정할 수 있지만, 특정 시간 동안만 대기하게 되어 타임아웃이 발생합니다.

다음의 의사 코드 스니펫은 작업에서 시간 지연(예: 절전, 수면 모드) RTOS 서비스를 사용하는 방법을 도시하고 있습니다. 빨간색 코드는 RTOS API를 나타냅니다. 작업을 1틱(즉, Tick Rate가 1000Hz인 경우 1밀리초) 지연하려면 2틱을 지정해야 할 수도 있다는 점에 주의해야 합니다! 그 이유는 CPU가 주어진 시간에 하나의 작업만 실행할 수 있기 때문이며, 해당 작업의 우선 순위가 낮을 경우 다음 틱이 도착하기 직전에 실행될 수 있기 때문에 해당 작업은 곧바로 재실행될 수 있습니다. 따라서 1밀리초만큼 지연되어야 할 경우, 실제로 전혀 지연되지 않을 수도 있습니다!

void Task (void)
{
  // Task initialization
  while (1) {
    Delay(#ticks);
    Perform some periodic work;
  }
}

 

다음의 의사 코드는 작업이 이벤트(ADC 변환, 이더넷 패킷 등)를 대기하고 타임 아웃을 지정하는 방법을 도시합니다. 이 경우, 이벤트가 발생할 때까지 무제한 대기하지 않도록 타임아웃이 사용됩니다. 프로그램이 특정한 시간 내에 성공적으로 수행되지 않아서 진행이 자동적으로 중단되는 타임아웃은, 하드웨어의 오류를 나타내는 것일 수 있으며 예상된 결과일 수도 있습니다.

void Task (void)
{
  OS_ERR  err;

  // Task initialization
  while (1) {
    err = WaitForEvent(&EventObject, timeout);
    if (err == TIMEOUT_OCCURRED) {
      Event didn’t happen within timeout;
    } else {
      Event occurred, process;
    }
  }
}

오해 #1: RTOS 틱은 스케쥴러 이다.

대체로 RTOS가 더 중요한 작업을 실행해야 하는지 여부를 결정하도록 하는 이벤트가 하나씩 발생할 때마다, 하나의 RTOS는 스케줄러를 실행합니다. Tick 인터럽트(즉, 이벤트)는 스케쥴러가 실행되도록 하는 RTOS 기반 시스템의 여러 이벤트 중 하나에 불과합니다! 따라서 이더넷 패킷이 도착하였고, 해당 이더넷 패킷이 작업을 대기 중인 이벤트인 경우, RTOS는 ISR(이더넷용)의 반환 직후 해당 작업의 실행 여부를 결정합니다.

오해 #2: RTOS 틱은 반드시 하나의 RTOS와 함께 사용해야만 한다.

RTOS들은 대부분 클럭 틱을 절실히 필요로 하지만, 애플리케이션이 작업을 절전 모드로 전환하지 않거나 타임아웃을 사용하지 않는 경우에는 시스템에서 간단히 생략할 수 있습니다! 물론 해당 기능(RTOS 틱)을 정말로 사용하고 있지 않은지를 확인해야 하는데, 이는 만일 RTOS 틱을 사용하고 있다면 작업이 예상대로 작동하지 않기 때문입니다. RTOS 틱의 사용 여부가 확실하지 않다면, RTOS 틱을 활성화하십시오.

오해 #3: RTOS 틱의 인터럽트는 가장 높은 우선순위여야 한다.

이는 절대적으로 사실이 아닌 것이, 시스템에서 가장 낮은 우선 순위의 인터럽트 중 하나인 RTOS 틱의 인터럽트도 만들 수 있고, 그렇지 않다고 하더라도 RTOS 틱의 우선순위는 애플리케이션의 실시간 인터럽트의 우선순위보다 확실히 낮기 때문입니다. 사용자는 아마도 아날로그 입력 샘플링, 고속 모터 제어, TCP/IP 트래픽에 대한 응답 등을 RTOS 틱보다 더 중요하게 간주할 것입니다. 그러나 RTOS 틱이란 시간 지연과 타임아웃을 개괄적으로 아우르는 개념입니다.

오해 #4: RTOS 틱은 반드시 정확해야 한다.

다시 한번 언급 드리자면, 틱의 전체적인 목적은 개략적인 시간 지연 및 타임아웃을 위한 시간을 제공하기 위함입니다. 매우 정확한 주기적 인터럽트를 필요로 하는 애플리케이션의 경우, 별도의 타이머를 사용하고 인터럽트를 높은 우선순위로 설정해야 합니다.

오해 #5: 클럭 틱은 전적으로 RTOS를 위한 것이어야 한다.

일반적으로 하드웨어 타이머를 RTOS에 할당하면 시간 지연 및 타임아웃에 사용되지만, RTOS가 기능을 수행하기 전에 타이머 인터럽트를 가로 막고 몇 가지 작업을 먼저 수행하고자 하는 경우도 있습니다. 특히, 일부 RTOS(예: uC/OS-III)에서는 RTOS 틱 서비스를 호출하기 전에 사용자 정의 함수(즉, 콜백 함수라고도 알려진 후크 함수, )를 호출할 수 있습니다. 해당 의사 코드는 다음의 스니펫과 같습니다.

RTOS_TickISR(void)
{
  Call user defined function; // i.e. a hook (a.k.a. callback)
  Call the RTOS tick services;
} 

하드웨어 타이머가 부족하거나 상당히 정확한 수준의 시간 소스를 필요로 할 경우, 위 코드로 구현되는 기능을 사용하고 싶을 것입니다. RTOS 전에 위와 같은 코드를 호출하면 RTOS 스케줄러로 인한 태스크 지터(task jitter)의 영향을 받지 않게 됩니다.

 

오해 #6:  하드웨어 타이머가 언제나 필요하다.

다시 설명 드리자면, 하드웨어 타이머가 부족하고 임베디드 시스템이 AC 전원으로 구동되는 경우, 단순히 계통 주파수를 추출하여 (하드웨어 엔지니어가 함께 작업해야 할 수 있음.) 50 또는 60Hz(국가에 따라 다름)를 얻을 수 있거나, 또는 전력선의 부호 변화점을 감지하여 주파수(100 또는 120Hz)의 두 배를 획득할 수 있습니다. 이에 따라, 적어도 미국에서는 하드웨어 타이머가 부족하고 임베디드 시스템이 AC 전원으로 구동되는 경우, 장기 정확도가 상대적으로 안정적이고 정확하다는 것이 밝혀졌습니다. 그러므로 AC 전원 전기 벽시계는 시간을 준수하는 것입니다.