RTOS와 순환 실행을 혼합하는 것이 합리적입니까?

Question

소규모 임베디드 시스템 프로젝트에는 스레드에서 실행하고 싶은 코드가 있으므로 임베디드 RTOS(eCos) 위에 빌드하기로 결정했습니다.

이전에는 각각 상태 머신으로 구현된 작업을 구동하는 main()의 순환 실행을 사용했습니다.일부 작업의 경우 작업을 여러 개의 세분화된 상태로 나누어 코드를 더욱 복잡하게 만드는 문제에 직면했습니다.

RTOS로 전환할 때 각 스레드 스택에 대한 메모리 사용량이 자체 스레드인 별도의 작업을 제공하면 빠르게 합산된다는 것을 발견했습니다.(64k만 있고 통신 버퍼용 메모리가 필요합니다)

우리는 커뮤니케이션 작업에 트레드를 사용하고 주기적 실행을 위해 다른 스레드를 사용하는 것을 고려하고 있습니다.순환 실행은 다른 논리적 작업을 추진합니다.

이렇게 RTOS와 순환 실행을 혼합하는 것이 합리적입니까?

Answer 1

이것은 완벽하게 유효한 디자인입니다.
우리 제품 중 하나에서는 비동기 I/O 채널(TCP/IP, 2개의 직렬 스트림)이 자체 작업에 있고 여러 기능 영역을 담당하는 "기본" 작업이 있는 유사한 디자인을 사용했습니다. .

작업을 디자인을 단순화할 수 있는 단순한 분할 메커니즘으로 생각하십시오.

Answer 2

예, 하나의 OS 스레드에서 여러 '작업'을 실행하는 순환 실행을 갖는 것이 합리적일 수 있습니다.실제로 두 작업이 일정 요구 사항과 충돌하지 않는 한(하나는 차단해야 하고, 하나는 다른 작업보다 우선 순위가 높으며, 우선 순위가 낮은 작업은 실행하는 데 오랜 시간이 걸리는 등), 동일한 스레드에 두는 것이 좋습니다.

메모리 보호 기능이 없는 경량 RTOS를 사용하는 경우 특히 그렇습니다.별도의 스레드는 하나의 스레드보다 안전하지 않습니다(주소 공간의 MMU 보호 없음). 실제로 동시성 보호에 대한 필요성이 더 크기 때문에 잠재적으로 더 위험합니다.IPC 체계가 강력하고 프로그래머가 오용할 위험이 없더라도 일반적으로 오버헤드는 0이 아니므로 이를 피하면 성능이 향상될 수 있습니다.

Answer 3

만약 너라면 FreeRTOS를 살펴보세요, 그들은 실제로 작업에서 다른 스케줄러를 실행합니다. :)

그리고 다른 사람들을 반영하기 위해 디자인에는 잘못된 것이 없습니다.그러한 방식으로 무언가를 표현하는 명확한 방법이 있다면 작업(일부)이 상태 머신이 될 수 없는 이유는 없습니다.

Answer 4

타당한 디자인인데, OS를 가지고 있는 이유를 전혀 놓친 것 같습니다.

OS의 어떤 기능을 사용할 계획입니까?

이용 가능한 정보에 따르면 작업의 복잡성을 새로운 메인 루프로 옮기게 될 것 같습니다.