IoT 애플리케이션은 RTOS 또는 Linux를 선택합니다.
Linux VS RTOS, 어떤 것을 선택해야 할까요?
소개
장치나 시스템을 개발할 때 가장 먼저 내려야 하는 가장 중요한 결정 중 하나는 실행될 운영 체제 유형을 결정하는 것입니다.
운영 체제는 특정 하드웨어를 기반으로 하는 대규모 시스템 수준의 소프트웨어로 리소스 관리, 스레드\프로세스 스케줄링, 스레드\프로세스 간 통신 및 동기화를 포함한 구성 요소의 모음입니다.
Linux는 종종 Android 스마트폰 및 스마트 TV에서 게임 콘솔 및 자동차에 이르기까지 많은 장치 및 프로젝트에서 기본 운영 체제로 선택되며 많은 장치에서 Linux 시스템을 사용합니다.
RTOS(실시간 운영 체제, RTOS)도 매우 일반적입니다. 일부 소형 게이트웨이, 스마트 시계, 의료 기기 또는 장난감은 장치의 운영 체제로 RTOS를 선택합니다.
리눅스
Linux는 범용 운영 체제(범용 운영 체제, GPOS)이며 임베디드 시스템의 응용 프로그램에는 일반적으로 주변 장치 드라이버 지원, 파일 시스템, 네트워크 연결 및 UI 지원이 포함됩니다. 이 모든 것을 RTOS에서 제공할 수 있지만(또는 기능의 이 부분을 잘라서) 일반적으로 지원 범위가 넓지 않거나 추가 비용이나 통합 작업이 필요합니다.
물론 이러한 Linux의 기능은 많은 양의 하드웨어 및 소프트웨어 리소스 지원이 필요한 반면 RTOS는 훨씬 적은 리소스를 필요로 하므로 필요한 비용도 이에 상응합니다.
또 다른 중요한 요소는 Linux가 실시간이 아니라는 것입니다. RTOS는 결정론적 동작과 이벤트 및 인터럽트에 대한 시기적절한 응답을 보장하기 위해 스케줄링 보장을 제공합니다.
RTOS
RTOS는 외부 이벤트에 대해 결정론적인 하드 실시간 응답을 제공한다는 점에서 Linux와 같은 기존 운영 체제와 다릅니다(우선순위가 높은 작업은 지정된 짧은 시간 내에 실행해야 합니다. 그렇지 않으면 폭발할 것입니다). 반면 기존 운영 체제는 비결정적 소프트 실시간 응답을 제공합니다. 실제로 이것은 RTOS 소프트웨어가 제한된 수의 예약된 작업에 대해 응답성이 높은 처리(기존 운영 체제보다 훨씬 빠름)를 제공 할 수 있는 반면 기존 Linux 운영 체제는 많은 수 의 다양한 작업을 처리하는 데 더 효율적이라는 것을 의미합니다.
비교하다
| 리눅스 | RTOS | |
|---|---|---|
| 실시간 | 소프트 실시간 Linux에는 실시간 스케줄러를 포함하여 많은 스케줄링 옵션이 있지만 이것은 기껏해야 "소프트" 실시간이며 실시간 Linux의 일반적인 대기 시간은 수십 또는 수백 마이크로초 정도입니다. Linux와 같은 범용 운영 체제(GPOS) 일반적으로 라운드 로빈과 같은 우선 순위 시분할 스케줄러는 많은 프로세스 간에 시간을 "공정하게" 분배하는 데 사용됩니다. 따라서 실행 중인 프로세스가 많을수록 더 바빠지고(사용 가능한 시간 조각을 더 많이 사용) 응답 속도가 느려집니다. | 하드 실시간, 일반적인 RTOS 실시간 커널은 0에서 몇 마이크로초(평균 시간이 아닌 최악의 경우)의 대기 시간을 달성할 수 있습니다. RTOS에는 일반적으로 선점 우선 순위 기반 스케줄러가 있으므로 우선 순위가 가장 높은 준비 작업이 즉시 실행되고 자체 일시 중단되거나 우선 순위가 더 높은 작업이 준비될 때까지 계속 실행됩니다. 프로그램을 RTOS에 넣는다고 해서 자동으로 실시간으로 되는 것은 아니며, 개발자는 모든 작업이 매번 제 시간에 실행되도록 하기 위해 우선순위를 적절하게 할당해야 합니다. 일반적으로 런타임이 가장 짧고 결정론적인 작업이 가장 높은 우선 순위를 가져야 합니다. |
| 리소스 요구 사항 | 원래 Linux는 데스크탑 PC용으로 개발되었습니다(x86 프로세서 아키텍처 기반). 200MIPS 이상의 많은 CPU 리소스, 32비트 프로세서, 이상적으로는 MMU, 4Mb ROM 및 16MB RAM이 부팅에 필요합니다(몇 초가 걸릴 수 있음). 일반적으로 8비트 또는 16비트에서는 작동하지 않습니다. MCU는 Linux 커널에 더 많은 온보드 RAM이 필요합니다. 예를 들어 ARM Cortex-M 아키텍처를 기반으로 하는 MCU에는 보통 수백 킬로바이트의 RAM만 있고 Linux는 이러한 칩에서 실행할 수 없습니다. | RTOS는 8비트 이상의 마이크로컨트롤러에서 밀리초 단위로 시작하고 10Kb 미만으로 실행할 수 있습니다. 8비트 아키텍처에서 두 가지 작업, 스케줄러, 통신 대기열 및 세마포어를 실행하는 매우 간단한 설정에는 약 200바이트의 RAM이 필요할 것입니다. |
| 안전 | 높음, Linux는 애플리케이션이 다른 프로세스나 커널 자체에서 사용하는 메모리에 액세스할 수 없는 적절한 프로세스 분리를 사용합니다. | 더 높은 |
| 개발 친화성 | 코드 추상화가 잘 되어 있어 포팅에 편리합니다. 많은 소프트웨어 및 하드웨어 드라이버, 점점 더 완벽한 디버깅 및 성능 분석 도구 지원 | 제한된 성능 분석을 지원하는 디버그 도구, 코드 호환성은 평균입니다. |
| 이해력 개발의 어려움 | Linux 기반 시스템의 부트 로더, 커널 및 루트 파일 시스템은 RTOS 기반 설계보다 최소한 몇 배 더 복잡합니다. | 낮은 |
| 장비 크기 | 더 크게 | 더 작은 |
| 저전력 소비 | 더 높은 전력 소비. 그리고 그것의 소비 전력 제어 방식을 이해하기 어렵다. | 낮은 소비 전력, 간단하고 효과적인 전력 소비 제어 방법 제공 |
| 비용 | Linux 시스템의 재료 명세서(BOM)는 약 $20부터 시작합니다. | 단일 칩 마이크로컨트롤러의 BOM은 약 3달러에 불과할 수 있습니다. |
| 하드웨어 드라이버 | Linux는 기성품 하드웨어 드라이버의 지배자이며 오늘날 많은 칩 공급업체는 Linux 드라이버만 제공합니다. 복잡한 하드웨어 드라이버로 작업하는 경우 상용 Linux 드라이버를 사용하면 작업 속도를 상당히 높일 수 있습니다. | 지원되는 하드웨어 드라이버가 제한됨 |
| 선택 제안 | 세분화된 수준의 실시간 성능으로는 부족합니다. 그러나 개발자 친화성 측면에서 개발 환경은 특히 저수준 코드에 대한 깊은 이해가 없는 사람들에게 훨씬 친근합니다. GPS 시스템에 필요한 대용량 데이터베이스와 같이 당면한 작업을 위해 많은 메모리가 필요한 경우 Linux의 추가 메모리는 문제가 되지 않습니다. 응답 시간이 인간의 인식을 기반으로 하는 경우(100ms보다 큰 대기 시간은 양호함) 상대적으로 낮은 실시간 성능은 문제가 되지 않습니다. | RTOS는 동시에 소수의 작업, 특히 실시간 요구 사항이 높은 소수의 작업만 실행할 수 있습니다. 훨씬 적은 코드, 훨씬 적은 복잡성, 훨씬 적은 오류 가능성이 있으므로 전체 시스템 작동 방식을 더 잘 제어할 수 있습니다. 저렴한 하드웨어, 빠른 응답성 및 어려운 개발 작업을 수행하려는 의지는 RTOS가 끝나는 곳이며 보완적인 측면은 Linux를 가리킵니다. |
요약하다
1) IoT 애플리케이션을 위해 Linux 또는 RTOS를 선택할 때 간단한 대답은 다음과 같이 시작됩니다. 실시간 요구 사항이 있는 경우 (이름에서 알 수 있듯이) RTOS를 사용해야 합니다.
2) 그 외에 모든 것은 실제 요구 사항(비용, 기능)에 따라 다릅니다. 또한 개발자가 익숙한 것에 따라 다릅니다. Linux 구성은 매우 어려울 수 있으며 때로는 간단한 RTOS가 더 쉽습니다.
(좋아요 또는 모아주셔서 감사합니다)