진짜

임베디드 프로젝트에 RTOS(실시간 운영 체제)를 사용해야 하는 경우는 언제입니까? 그것이 테이블에 무엇을 가져오며, 비용은 얼마입니까? 다행스럽게도 RTOS가 프로젝트에 적합한 선택인지 파악하는 데 도움이 될 수 있는 엄격한 기술 정의가 있습니다.

이름의 "실시간" 부분은 RTOS의 기본 전제, 즉 특정 유형의 작업이 미리 정의된 결정론적 시간 범위 내에 완료된다는 보장을 포괄합니다. "실시간" 내에는 하드 실시간, 확고한 실시간, 소프트 실시간이라는 별개의 범주가 있으며 마감일을 놓친 경우 처벌이 점점 덜 엄격해집니다. 하드 실시간 시나리오의 예로, 내장형 컨트롤러가 특정 시간 내에 들어오는 센서 데이터에 응답해야 하는 시스템을 상상해 보세요. 이러한 기한을 놓친 결과로 인해 시스템의 다운스트림 구성 요소가 비유적으로나 문자 그대로 중단된다면 기한을 맞추기가 어렵습니다.

이에 비해 소프트 실시간은 컨트롤러가 이 시간 내에 응답하면 좋겠지만, 조금 더 오래 걸리면 전혀 문제가 없는 작업입니다. 하드 실시간 기능이 가능한 운영 체제도 있지만 그렇지 않은 운영 체제도 있습니다. 이는 대부분 기본 설계, 특히 스케줄러의 요소입니다.

이 문서에서는 다양한 운영 체제를 살펴보고 이러한 정의에 적합한 위치와 프로젝트에서 이를 언제 사용하려는지 살펴보겠습니다.

다양한 임베디드 OS는 다양한 유형의 시스템을 다루며 다양한 기능 세트를 가지고 있습니다. 널리 사용되는 RTOS 중 가장 최소한의 것은 아마도 FreeRTOS일 것입니다. 이는 스케줄러와 함께 스레드, 뮤텍스, 세마포어 및 스레드로부터 안전한 힙 할당 방법을 포함한 멀티스레딩 기본 요소를 제공합니다. 프로젝트의 필요에 따라 다양한 동적 할당 방법 중에서 선택할 수 있을 뿐만 아니라 정적 할당만 허용할 수도 있습니다.

규모의 반대편에는 실시간 스케줄러 패치가 적용된 VxWorks, QNX 및 Linux와 같은 RTOS가 있습니다. 이는 일반적으로 POSIX 인증 또는 호환 운영 체제로, 일반 데스크톱 플랫폼과 고도로 호환되는 플랫폼 개발의 편의성을 제공하는 동시에 스케줄링 모델을 통해 어느 정도 실시간 성능을 보장합니다.

다시 말하지만, RTOS는 스케줄러가 작업 전환 시 특정 수준의 결정성을 보장하는 경우에만 RTOS입니다.

운영 체제 영역 외부에서도 프로세서의 실시간 성능은 크게 다를 수 있습니다. 이는 마이크로컨트롤러와 인터럽트를 처리하는 데 필요한 사이클 수를 볼 때 특히 분명해집니다. 예를 들어 널리 사용되는 Cortex-M MCU의 경우 인터럽트 대기 시간은 가장 좋은 경우 12주기(M3, M4, M7)에서 23+(M1) 범위로 제공됩니다. 프로세서 속도로 나누면 1/4 마이크로초 정도가 됩니다.

이에 비해 Microchip의 8051 MCU 제품군을 살펴보면 섹션 2.16.3('응답 시간')의 'Atmel 8051 마이크로컨트롤러 하드웨어 매뉴얼'에서 인터럽트 구성에 따라 인터럽트 대기 시간이 어디에나 있을 수 있음을 알 수 있습니다. 3~8사이클. x86 플랫폼에서는 x86 IRQ의 다소 복잡한 특성으로 인해 이야기가 다시 더 복잡해집니다. 다시 말하지만, 마이크로초의 일부입니다.

이 대기 시간은 RTOS가 달성할 수 있는 최고의 실시간 성능에 절대적인 한계를 두지만, 스케줄러 실행으로 인한 오버헤드로 인해 RTOS는 이 한계에 근접하지 않습니다. 이것이 바로 최고의 실시간 성능을 위해서는 수신 이벤트에 대한 빠른 인터럽트 핸들러 루틴을 갖춘 결정론적 단일 폴링 루프 접근 방식이 가장 결정론적인 이유입니다.

인터럽트 또는 기타 컨텍스트 전환으로 인해 주기 비용이 많이 드는 경우 기본 프로세서를 더 빠르게 실행하면 대기 시간도 확실히 줄어들지만 다른 절충안이 따르며 그 중 가장 중요한 것은 더 높은 전력 사용량과 증가된 냉각 요구 사항입니다.

FreeRTOS에서 알 수 있듯이 OS 추가의 기본 포인트는 멀티태스킹(및 멀티스레딩) 지원을 추가하는 것입니다. 이는 일종의 스케줄링 메커니즘을 사용하여 프로세서 시간을 다양한 작업 또는 스레드가 활성화될 수 있는 '조각'으로 나눌 수 있는 스케줄러 모듈을 의미합니다. 가장 쉬운 멀티태스킹 스케줄러는 각 스레드가 자발적으로 양보하여 다른 스레드가 작업을 수행하도록 허용하는 협동형 스케줄러이지만 이는 각 스레드가 다른 스레드의 모든 것을 망칠 수 있다는 뚜렷한 단점이 있습니다.