임베디드 시스템 설계에 운영 체제가 필요한 시점은 언제입니까?

22

PIC 및 x86 프로세서 용 베어 메탈 코드를 많이 작성했습니다. 운영 체제가 필요한시기와 방법을 누군가에게 알려줄 수 있습니까? 반대로, 운영 체제와 함께 또는 운영 체제없이 처리 할 수있는 응용 프로그램 또는 상황은 무엇입니까?

embedded operating-system

— 양자 231
소스

2

학교에서 알아야 할 것이 전부는 아니기 때문입니다. RTOS를 배울 필요가 있다고 생각되면 플랫폼을 선택하여 배우십시오.

— Scott Seidman

3

임베디드에서 OS 사용에 관한 질문은 유효합니다. 그러나 EE.SE는 "학교에서 왜 이것을 가르쳐주지 않았습니까?" 부품. 나는 그것을 편집하기 위해 자유를 가져 갔다.

— Nick Alexeev

가능한 복제 내 장치에 OS가 필요합니까?

— Kaz

제가 왜 제가 왜 대학교에서 가르치지 않았는가에 대한 유일한 이유는 아직 대학교에서 공부 한 EE 학생을 본 적이 없기 때문입니다. 따라서 그것은 어떤 대학에서도 전혀 이루어지지 않은 것 같습니다.

— quantum231

@ quantum231 그것은 나의 대학, NTNU-노르웨이에서 이루어졌다.

— CK

23

제 경험에 따르면 제품에 다음 중 하나 이상이 필요한 경우 운영 체제를 고려해야합니다. TCP / IP 스택 (또는 다른 복잡한 네트워킹 스택), 복잡한 GUI (아마도 Windows 및 이벤트와 같은 GUI 객체가있는 것) ) 또는 파일 시스템입니다.

베어 메탈 코딩을 수행했다면 아마도 슈퍼 루프 프로그램 아키텍처에 익숙 할 것입니다 . 제품의 펌웨어 요구 사항이 유지 관리가 가능하고 (확실히 다소 확장 가능한) 수퍼 루프로 구현 될 정도로 단순하다면 운영 체제가 필요하지 않을 수 있습니다.

소프트웨어 요구 사항이 증가함에 따라 수퍼 루프가 더욱 복잡해집니다. 소프트웨어 요구 사항이 너무 많아 수퍼 루프가 너무 복잡해 지거나 시스템의 실시간 요구 사항을 충족시킬 수없는 경우 다른 아키텍처를 고려해야합니다.

RTOS 아키텍처를 사용하면 소프트웨어 요구 사항을 작업으로 나눌 수 있습니다. 올바르게 수행하면 각 작업의 구현이 단순화됩니다. 또한 작업 우선 순위를 지정하면 RTOS를 통해 실시간 요구 사항을보다 쉽게 이행 할 수 있습니다. 그러나 RTOS는 만병 통치약이 아닙니다. RTOS는 전반적인 시스템 복잡성을 증가시키고 교착 상태와 같은 새로운 유형의 버그를 엽니 다. RTOS의 대안으로 이벤트 기반 상태 머신 아키텍처 (예 : QP )를 고려할 수 있습니다 .

제품에 네트워킹, 복잡한 GUI 및 파일 시스템이있는 경우 VxWorks, Windows 또는 Linux와 같은 모든 기능을 갖춘 운영 체제를 고려해야합니다. 모든 기능을 갖춘 운영 체제에는 상세 수준의 드라이버가 포함되어 있으며 응용 프로그램에 집중할 수 있습니다.

— 크르 람보
소스

8

그것은 실제로 '내장 시스템'의 정의에 달려 있습니다. 베어 메탈 프로그래밍이 아니라면 내장되어 있지 않다고 주장하는 사람들이있을 수 있습니다 (귀하의 질문을 배제), 나는 동의하지 않을 것입니다-나는 하나의 기능 만 수행하도록 설계된 시스템이라면, 즉, 하나의 특정 '응용 프로그램'만 실행하는 것을 임베디드 시스템이라고 할 수 있습니다.

즉, 완전한 OS의 서비스로 이익을 얻을 수있는 상황을 상상하기가 매우 쉬워야합니다. 예를 들어, 내가 일하는 곳에서는 창문 위에서 실행되는 계측 디자인 제품군 위에 테스트 장비를 구축하는 사람들을 찾는 것이 일반적입니다. 이 시스템은 테스트 스테이션 구성으로 부팅하고 일반적인 사용을 차단하여 (스테이션 손상을 방지하기 위해) 내장 시스템입니다.

그러나 기성품 I / O 모듈을 구입하여 랙 마운트 PC에 꽂고 GUI에서 구성을 구성 하면 일부 는 임베디드 시스템 설계 로 자격을 갖추지 못할 수 있습니다 . 기성품이 적은 상황에서는 멋진 데이터 로깅을 수행하려는 FPGA가있는 사용자 정의 프로세스 컨트롤러를 고려하십시오. 소프트 코어 프로세서 시스템 (기존 BSP 포함)을 임베드하고 실시간 리눅스를 실행하여 로깅 및 NTP 등의 네트워크 스택을 실행하고 다른 모든 작업을 논리로 수행 할 수 있습니다.

— 저스트 제프
소스

7

내 (매우 모호한) 경험의 규칙은 하나 이상의 제어 스레드 (예 : 프로토콜 또는 상태 머신을 포함하는 하나 이상의 장치와 다른 것을 수행해야 함)가 필요한 경우 OSish 소프트웨어의 일부는 삶을 더 쉽게 만들 것입니다

— 타니 하
소스

RTOS 설정에는 일정량의 작업이 필요합니다. switch기반 상태 머신 을 사용하려는 노력 이이를 초과 하지 않는 한, switch기반 머신이 더 나은 경향이 있습니다. 또한 8x51 및 TMS2000 플랫폼 모두에서 간단한 스택 기반 협업 작업 전환기를 구현했습니다. 언제 전환해야할지 결정하는 OS 논리가 없습니다. 하나의 "스레드"가 중단 될 수 있다고 생각하면 언제든지 다른 스레드로 전환됩니다. 다른 스레드가 대기중인 무언가가 아직 발생하지 않은 것을 발견하면 일반 OS가 전환 여부 를 결정 하는 데 소비 한 시간보다 짧은 시간에 처음으로 다시 전환 할 수 있습니다.

— supercat

진정한 소프트웨어 멀티 태스킹 "스레드"(OS를 많이 가리킴)와 하드웨어 조건에 응답하는 간단한 인터럽트를 구분할 가치가 있습니다.

— Chris Stratton

1

오래된 질문이지만 어쨌든 언급하겠습니다.

네트워크 스택 또는 이와 유사한 것이없는 경우에도 임베디드 응용 프로그램에 충분한 프로세스가 있으므로 작업 스케줄러가 필요한 시점에서 RTOS를 고려할 수 있습니다. 간단한 타이머 기반의 협업 멀티 태스킹 스케줄러를 작성하는 것은 그리 어렵지 않지만 멈춰진 프로세스가 나머지 응용 프로그램을 차단하지 못하므로 올바른 시간이 걸릴 수 있습니다. 프로세스가 완료되지 않은 경우 대기열에서 프로세스를 중단시키기 위해 일종의 프로비저닝으로 우선 순위 시스템을 구현해야합니다.

RTOS는 또한 메모리 보호와 같은 것들을 제공하여 C 코드에서 일부 일반적인 기린을 훨씬 쉽게 추적 할 수 있지만 간단한 마이크로 컨트롤러는 복잡한 메모리 보호를 처리하지 못할 수 있습니다. 예를 들어 MSP430을 사용하면 코드와 데이터를 높은 수준으로 분리 할 수 있지만 미세한 메모리 액세스 제어는 없습니다.

— 보리 맨
소스

0

실제로 운영 체제는 장치 드라이버를 통해 하드웨어와 응용 프로그램 소프트웨어 간의 격차를 해소합니다. 즉, 프로그래머에게 비교적 높은 수준의 플랫폼을 제공하여 궁극적으로 코드 복잡성을 줄입니다. 또한 운영 체제는 응용 프로그램 실행을위한 강력하고 유연한 플랫폼을 제공합니다.

— 마치
소스