임베디드 시스템을위한 RTOS

시간 관리 및 리소스 관리에 RTOS를 사용해야한다고 말하는 많은 기사를 보았습니다. 내 시간은 내 자신의 연구를 허용하지 않았으므로 나는 조언을 구하기 위해 chiphacker에 온다.

저자 원 마이크로 컨트롤러 (MSP430, PIC)를 사용하며 사용할 수있는 RTOS를 찾고있었습니다.

요점 :

1. 시스템의 자원 비용
2. 시스템의 장점
3. 시스템의 단점
4. 구현 요령
5. RTOS를 사용해서는 안되는 상황.

나는 arduino와 같은 시스템을 사용하지 않습니다. 함께 작업하는 프로젝트는 그러한 시스템의 비용을 지원할 수 없습니다.

QNX 이외의 RTOS에 대한 개인적인 경험이 많지 않았습니다. (전체적으로 훌륭하지만 저렴하지는 않으며 특정 보드 공급 업체와는 전혀 다른 경험이 있습니다. PIC 및 MSP430에는 너무 큽니다.

RTOS의 이점은 다음과 같은 분야에 있습니다.

• 스레드 관리 / 스케줄링
• 스레드 간 통신 + 동기화
• stdin / stdout / stderr 또는 직렬 포트 또는 이더넷 지원 또는 파일 시스템이있는 시스템의 I / O (직렬 포트를 제외하고 대부분 MSP430 또는 PIC가 아님)

PIC 또는 MSP430 주변 장치의 경우 : 직렬 포트의 경우 링 버퍼 + 인터럽트를 사용합니다. 시스템 당 한 번 작성하고 재사용하는 것입니다. 다른 주변 장치 벤더마다 RTOS가 많이 지원한다고 생각하지 않습니다.

마이크로 초에 딱딱한 타이밍이 필요한 경우 RTOS가 도움이되지 않을 수 있습니다. RTOS는 타이밍을 제한했지만 컨텍스트 전환 지연으로 인해 스케줄링에 타이밍 지터가 있습니다 ... PXA270에서 실행되는 QNX는 일반적으로 수십 마이크로 초에서 지터가 100-200us 최대치이므로 약 100Hz보다 빠르게 실행되거나 약 500us보다 훨씬 정확한 타이밍이 필요한 제품에는 사용하지 않습니다. 이런 종류의 것들을 위해서는 아마도 자신의 인터럽트 처리를 구현해야 할 것입니다. 일부 RTOS는 그것과 잘 어울릴 것이고, 다른 RTOS는 그것을 왕의 고통으로 만들 것입니다 : 당신의 타이밍과 타이밍이 잘 공존하지 못할 수도 있습니다.

타이밍 / 스케줄링이 너무 복잡하지 않으면 잘 설계된 상태 머신을 사용하는 것이 좋습니다. 실제 상태 차트를 C / C ++로 읽는 것이 좋습니다 . 우리는 내가 작업하는 일부 프로젝트에서이 접근 방식을 사용했으며, 복잡성을 관리하기 위해 기존의 상태 머신보다 실질적인 이점을 얻었습니다. 이것이 RTOS가 필요한 유일한 이유입니다.

FreeRTOS 를 사용해 보셨습니까 ? 그건 무료 (T & C에 따라) 및 MSP430 및 PIC의 여러 가지 맛을 모두 포팅되었습니다.

다른 것들에 비해 작지만 특히 RTOS를 사용하지 않은 경우 쉽게 배울 수 있습니다.

IEC 61508 / SIL 3 버전뿐만 아니라 (무료) 상업용 라이센스가 제공됩니다.

NuttX RTOS 에 대해 알게되었으며 8052 (8 비트) 시스템에서도 작동합니다. 포트가 많지 않지만 흥미로워 보입니다. POSIX는 강력한 프로세서로 이동하고 실시간 Linux 또는 QNX를 실행하려는 경우 일부 코드를 좀 더 이식성이 좋게 만들 수 있기 때문에 장점이 될 수 있습니다.

상용 RTOS 자체에 대한 경험은 없지만 수년간 수제를 사용했습니다! 그들은 많은 프로그래머들 사이에서 코드 개발을 나눌 수 있도록 도와줍니다. 그들은 본질적으로 각자 "작업"또는 "스레드"를 얻을 수 있기 때문입니다. 당신은 여전히 ​​조정을해야하며 누군가가 전체 프로젝트를 감독하여 각 작업이 마감일을 지킬 수 있도록해야합니다.

RTOS를 사용할 때 Rate Monotonic Analysis 또는 RMA 를 연구하는 것이 좋습니다 . 이를 통해 중요한 작업이 마감일을 지키도록 보장 할 수 있습니다.

또한 RTOS의 유무에 관계없이 실시간 기능을 제공 할 수있는 Miro Samek의 QP-nano 이벤트 중심 프로그래밍 프레임 워크를 살펴 보겠습니다 . 이를 통해 기존 작업 대신 디자인을 계층 적 상태 시스템으로 나눕니다. Jason S는 그의 게시물에서 Miro의 책을 언급했습니다. 대단한 독서!

여러 컴퓨터에서 유용한 것으로 밝혀진 것은 간단한 스택 스위처입니다. 실제로 PIC 용으로 작성하지는 않았지만 두 스레드 / 모든 스레드가 총 31 이하의 스택 레벨을 사용하는 경우 PIC18에서 접근 방식이 제대로 작동 할 것으로 기대합니다. 8051에서 주요 루틴은 다음과 같습니다.

_taskswitch :
  xch a, SP
  xch a, _altSP
  xch a, SP
  ret

PIC에서 스택 포인터의 이름을 잊었지만 루틴은 다음과 같습니다.

_taskswitch :
  movlb _altSP >> 8
  movf _altSP, w, b
  movff _STKPTR, altSP 
  movwf _STKPTR, c
  반환

프로그램 시작시, 대체 스택의 주소로 altSP를로드하고 (16은 PIC18Fxx에서 잘 작동 할 수 있음) task2 루프를 실행하는 task2 () 루틴을 호출하십시오. 이 일과는 결코 돌아 오지 않아야합니다. 대신 기본 작업에 대한 제어 권한을 원할 때마다 _taskswitch를 호출해야합니다. 그런 다음 기본 작업은 보조 작업을 수행 할 때마다 _taskswitch를 호출해야합니다. 종종 다음과 같은 귀여운 작은 루틴이 있습니다.

void delay_t1 (부호없는 짧은 값)
{
  하다
    taskswitch ();
  while ((부호없는 짧은) (밀리 초 _ 시계-val)> 0xFF00);  
}

작업 전환기에는 '조건 대기'를 수행 할 수있는 방법이 없습니다. 그것이 지원하는 것은 spinwait입니다. 반면에 작업 전환이 너무 빨라서 다른 작업이 타이머 만료를 기다리는 동안 taskswitch ()를 시도하면 다른 작업으로 전환되고 타이머를 확인한 후 일반적인 작업 전환기보다 빠르게 다시 전환됩니다. 작업 전환이 필요하지 않다고 판단합니다.

협력적인 멀티 태스킹에는 몇 가지 제한이 있지만 일시적으로 방해가되는 불변이 빠르게 재 확립 될 수있는 경우 많은 잠금 및 기타 뮤텍스 관련 코드가 필요하지 않습니다.

(편집) : 자동 변수 등에 관한 몇 가지주의 사항 :

1. 작업 전환을 사용하는 루틴이 두 스레드에서 호출되는 경우 일반적으로 두 개의 루틴 사본을 컴파일해야합니다 (아마도 #define 문이 동일한 # 동일한 소스 파일을 두 번 포함). 주어진 소스 파일에는 하나의 스레드에 대한 코드 만 포함되거나 그렇지 않으면 각 스레드에 대해 두 번 컴파일되는 코드가 포함되므로 "#define delay (x) delay_t1 (x)"또는 사용중인 스레드에 따라 #define delay (x) delay_tx (x) "
2. 호출되는 함수를 "볼"수없는 PIC 컴파일러는 이러한 함수가 모든 CPU 레지스터를 폐기 할 수 있다고 가정하므로 작업 스위치 루틴에서 레지스터를 저장할 필요가 없습니다. 선점 형 멀티 태스킹]. 다른 CPU에 대해 유사한 작업 전환기를 고려하는 사람은 사용중인 레지스터 규칙을 알고 있어야합니다. 적절한 스택 공간이 있다고 가정 할 때 작업 전환 전에 레지스터를 푸시하고 이후에 팝하는 것이 쉬운 방법입니다.

협동 멀티 태스킹은 잠금 문제를 완전히 피할 수는 없지만 실제로는 크게 단순화합니다. 예를 들어, 압축 가비지 수집기가있는 선점 형 RTOS에서는 개체를 고정 할 수 있어야합니다. 협동 스위처를 사용할 때 taskswitch ()가 호출 될 때마다 GC 객체가 움직일 수 있다고 가정하는 경우 필요하지 않습니다. 고정 된 물체에 대해 걱정할 필요가없는 압축 수집기는 그렇게하는 것보다 훨씬 간단 할 수 있습니다.

MSP430에서 Salvo 를 사용했습니다 . 이것은 프로세서 리소스에 매우 가벼워서 구현 규칙을 준수하고 사용하기 쉽고 안정적입니다. 이것은 협업 OS이며 작업 기능은 작업 기능의 외부 기능 호출 수준에서 수행되어야합니다. 이 제약 조건으로 인해 OS는 작업 컨텍스트를 유지 관리하는 방대한 양의 스택 공간을 사용하지 않고도 매우 작은 메모리 장치에서 작동 할 수 있습니다.

AVR32에서 FreeRTOS를 사용하고 있습니다. 지금까지도 매우 안정적 이었지만 FreeRTOS가 게시하는 버전과 Atmel 프레임 워크와 함께 제공된 버전간에 구성 / 버전 불일치가있었습니다. 그러나 이것은 무료라는 이점이 있습니다!

Everyday Practical Electronics 의 12 월호는 PIC를위한 실시간 운영 체제 (PIC n 'Mix Column) 시리즈의 3 부이며 MPLAB 및 PICKit 2를 사용하여 FreeRTOS를 설정하는 방법에 대해 자세히 설명합니다. 보지 못함)은 다양한 RTOS의 장점을 논의하고 FreeRTOS에 정착 한 것으로 보입니다. 현재 기사가 개발 환경을 설정하면 바이너리 디지털 시계 디자인을 시작합니다. 이 주제에 대해 적어도 하나 이상의 부분이있을 것으로 보입니다.

미국에서 EPE를 사용할 수 있는지 확실하지 않지만 사이트에서 연결된 미국 상점이있는 것으로 보이며 전자 사본이있을 수 있습니다.

PIC 용 CCS 컴파일러는 간단한 RTOS와 함께 제공됩니다. 나는 그것을 시도하지 않았지만이 컴파일러가 있다면 실험하기가 쉽다.

밀접하게 관련된 질문 : https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

당신은 당신의 응용 프로그램에 대해별로 말하지 않았습니다. RTOS 사용 여부는 PIC에서 수행해야 할 작업에 따라 다릅니다. 엄격한 시간 제한이 필요하거나 여러 스레드가 실행되는 여러 가지 비동기 작업을 수행하지 않으면 RTOS가 과도 할 수 있습니다.

가장 중요한 것에 따라 마이크로 컨트롤러에서 시간을 구성하는 방법에는 여러 가지가 있습니다.

1. 일정한 프레임 속도 : 예를 들어 1000Hz로 실행해야하는 서보 컨트롤러를 실행하는 PIC의 경우. PID 알고리즘이 실행하는 데 1ms 미만이 걸리면 나머지 밀리 초를 사용하여 CAN 버스 확인, 센서 읽기 등과 같은 다른 작업을 수행 할 수 있습니다.

2. 모든 인터럽트 : PIC에서 발생하는 모든 것은 인터럽트에 의해 트리거됩니다. 인터럽트는 이벤트의 중요성에 따라 우선 순위를 지정할 수 있습니다.

3. 루프에 집어 넣고 가능한 빨리 모든 것을하십시오. 적절한 시간 제한을 제공 할 수 있습니다.