MCU 프로그래밍에서 RTOS와 Bare Metal의 장점은 무엇입니까?

참고 : 이 질문은 특히 두 개의 RTOS를 언급하지만 더 일반적이며 임베디드 RTOS에 대한 C 코드를 작성하고 소프트웨어를 MCU에서 직접 실행 한 사람이 대답 할 수 있습니다.

임베디드 RTOS에 대해 더 많이 배우고 애플리케이션을 작성하는 데 관심이 있습니다. 저는 현재 Embox 와 RIOT를 보고 있습니다. 오픈 소스이고 현대적이며 활동적이며 훌륭한 문서를 가지고있는 것 같습니다. 저의 목표는 두 단계로 구성됩니다. 1 단계는 이러한 OS를 MCU (아마도 AVR 또는 ARM)로 컴파일하고 플래시하는 방법을 알아내는 것입니다. 2 단계는 시간이지나면서 "취미 앱"으로 발전하는 간단한 C 프로그램 (기본적으로 헤드리스 데몬)을 작성하는 것입니다. 그런 다음이 프로그램을 동일한 MCU에 플래시 / 배포하여 Embox / RIOT와 그 위에있는 앱으로 구성된 앱스 택을 성공적으로 배포했습니다.

결국 막 다른 길로 이어지는 길을 가기 전에이 기사 를 우연히 발견 하여 C / 어셈블러로 작성되고 MCU에 플래시 된 실시간 앱이 실제로 그 아래에 RTOS가 필요 하지 않은 이유를 설명 합니다. .

그래서 나는 정말로 혼란스러워하고 컴퓨팅 이론에 대한 나의 기본적인 이해에 의문을 제기하고 있습니다. 우선 Embox / RIOT를 사용할지 여부를 결정하려고합니다.

• 코스를 유지하고 OS + 앱의 MCU에서 "앱 스택"으로 이동하십시오. 또는
• 기사의 경고에 유의하고 내 앱 "베어 메탈"을 실행하는 MCU를 사용하십시오.

분명히 전자는 더 많은 일을하므로 그 길을가는 데는 합당한 이유가 있습니다. 그래서 나는 묻습니다. 이 (및 유사한) 내장 RTOS가 MCU / C 앱 개발자에게 제공 하는 실제 이점 은 무엇 입니까? RTOS를 사용하면 C 앱이 어떤 특별한 기능을 활용할 수 있습니까 (아마도 바퀴를 다시 만들지 않습니까?)? RTOS를 버리고 베어 메탈로 잃어버린 것은 무엇입니까?

RTOSes에 대한 wikipedia 항목으로 이동하면 얻을 수있는 미디어 과대 광고가 아니라 구체적인 예를 요청합니다. ;-)

마이크로 컨트롤러 프로그램은 여러 작업 으로 구성됩니다 . 컴퓨터 제어 망원경 마운트를 원한다고 가정 해 봅시다. 작업은 다음과 같습니다.

• USB 직렬 버퍼에서 새로운 입력 바이트를 검색합니다.
• 완전한 명령을 받았는지 확인하십시오.
• 그렇다면 해당 명령을 실행하십시오.
• 현재 망원경 위치의 센서를 읽습니다.
• 모터의 다음 단계를 제어하기 위해 적절한 출력을 설정하십시오.

이것은 마이크로 컨트롤러를 사용하는 것에 대한 상당히 일반적인 작업 세트이며 다음과 같이 무한 루프로 관리하기가 매우 쉽습니다.

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

기능을 계속 추가하고 추가하면 결국 다음과 같은 추상화를 생성하려는 일반적인 문제가 발생하기 시작합니다.

• 버퍼가 넘치므로 오버플로 전에 다른 작업을 중단 할 수 있는지 확인하려고합니다.
• 아무것도 필요 없을 때 잠을 자면 배터리를 절약 할 수 있습니다.
• 모든 작업이 공정하게 이루어 지길 원합니다. 경우 readSensors너무 오래 걸립니다, 당신은 그것을 중단하고 나중에 다시 올 수 있어야합니다.
• 하나의 작업을 다른 작업에 영향을주지 않고 재설정 할 수 있기를 원합니다.
• 한 작업에서 메모리 누수 또는 기타 버그가 발생하여 다른 작업을 수행하지 않으려 고합니다.
• 다른 작업에 다른 우선 순위를 부여 할 수 있기를 원합니다.
• 신뢰할 수없는 작업을 샌드 박스 할 수 있기를 원합니다.
• 다른 속도로 작업을 실행할 수 있기를 원합니다. 아마도 센서는 초당 10 회만 읽을 수 있지만 초당 100 번 모터 단계를 실행하려고합니다.

이러한 항목 중 하나 또는 둘을 비교적 쉽게 수동으로 처리 할 수 ​​있습니다. 이러한 종류의 문제가 라이브러리에 일반화되기 시작할 정도로 충분할 경우 RTOS를 기본적으로 재창조 한 것입니다. 프로그램의 작업 관리가 충분히 복잡한 경우, 상용 RTOS를 사용하지 않더라도 결국에는 잘못 개발하게됩니다.

그러나 내 경험에 따르면 RTOS를 원하는 라인은 마이크로 컨트롤러 대신 마이크로 프로세서를 원하는 라인에 매우 가깝습니다. 펌웨어가 복잡해질 것으로 예상되는 경우 일반적으로 마이크로 프로세서 경로를 처음부터 시작하는 것이 좋습니다.

ARM Cortex-M0을위한 자체 협업 멀티 스레딩 라이브러리를 작성했습니다.

코드는 거의 두 페이지가 아니며 첫 번째 버전은 작성하고 디버깅하는 데 하루 이상 걸리지 않았습니다.

Roll-your-own의 큰 장점은 코드를 알고 RTOS가 지원하지 않는 칩으로 코드를 이식 할 수 있다는 것입니다. 또한 "기능 A와 B를 동시에 사용하려고하면 충돌이 발생합니까?"와 같은 질문에 대해 생각하는 시간이 줄어 듭니다. 코드를 작성 했으므로 답을 알고 있습니다.

스레딩은 RTOS에서 얻는 주요한 것이므로 직접 구현하는 것은 그리 큰 일이 아닙니다. RTOS의 많은 기능이 필요한 경우는 드 rare니다. 그러나 요구 사항을 충족시키고 요구하는 경우 RTOS를 사용하십시오.