작은 임베디드 시스템 프로젝트에서 우리는 스레드에서 실행하고자하는 코드를 가지고 있으므로 임베디드 RTOS (eCos) 위에 빌드하도록 선택합니다.RTOS와 주기적 임원을 섞는 것이 합리적입니까?
이전에는 주 컴퓨터 (state machine)로 구현 된 작업을 수행하는 main()의주기 실행 파일을 사용했습니다. 일부 작업의 경우 작업을 많은 세분화 된 상태로 나누어 코드를 복잡하게 만드는 문제가 발생했습니다.
RTOS로 전환 할 때 각 스레드의 메모리 사용량이 빠르게 증가한다는 것을 알게되었습니다. (우리는 64k 만 가지고 통신 버퍼를위한 메모리가 필요합니다)
우리는 통신 작업에 트레드를 사용하고 주기적으로 임원을 위해 다른 스레드를 사용할 것을 고려하고 있습니다. 주기적 집행은 다른 논리적 인 업무를 이끌 것입니다.
이와 같이 RTOS와 주기적 집행을 혼합하는 것이 합리적입니까?
이것은 완전히 유효한 디자인입니다.
우리 제품 중 하나에서 우리는 비동기 I/O 채널 (TCP/IP, 2 직렬 스트림)이 자체 태스크에 있고 우리가 여러 영역을 담당하는 "메인"태스크를 가지고있는 비슷한 디자인을 사용했습니다 의 기능.
작업을 단순화하여 설계를 단순화 할 수있는 분할 메커니즘으로 생각하십시오.
유효한 디자인이지만 OS를 가지고있는 이유를 놓친 것 같습니다.
사용하려는 OS의 기능은 무엇입니까?
사용할 수있는 정보를 통해 작업의 복잡성이 새로운 주요 루프로 옮겨가는 것 같습니다.
예, 여러 개의 '작업'을 실행하는 하나의 OS 스레드에서 순환 실행 파일을 사용하는 것이 좋습니다. 실제로 두 가지 작업이 스케줄링 요구와 충돌하지 않는 한 (하나는 차단해야하며 하나는 다른 것보다 우선 순위가 높고 우선 순위가 낮은 것은 실행하는 데 시간이 오래 걸림) 같은 스레드에 넣는 것이 좋습니다.
이것은 메모리 보호 기능이없는 경량 RTOS를 사용하는 경우 특히 그렇습니다. 별도의 스레드는 하나의 스레드보다 안전하지 않으며 (주소 공간의 MMU 보호 기능 없음), 실제로는 잠재적으로 더 많은 메모리입니다 동시성 보호가 더 필요하기 때문에 위험합니다. IPC 체계가 강력하고 프로그래머가 오용을 일으키지 않는 경우에도 오버 헤드는 대개 0이 아니므로 성능 요구가 높아지면 성능이 향상 될 수 있습니다.
당신 look at FreeRTOS 경우, 실제로 :) 종류의 작업에
을 다른 스케줄러를 실행하고 다른 사람을 에코, 아무것도 설계에 잘못된 소리를하지 않습니다. 어떤 식 으로든 표현할 수있는 확실한 방법이 있다면 어떤 이유 (어떤 작업)도 상태 머신이 될 수 없습니다.
선점 형 스레딩 기능을 사용하면 통신 작업에 지나치게 복잡한 상태 시스템을 구축하지 않아도됩니다. 통신 부분을위한 스레드를 가짐으로써 코드는 꽤 간단합니다. 우리가 현재 sleep (1000) 타입의 블록을 가지고있는 모든 포인트에서 상태를 깨면 코드는 기본적으로 매우 작은 상태의 스파게티 코드 엉망이 될 것입니다. 그러나 코드를 깨끗하고 유지 보수하기 쉽게 유지할 수 있습니다. 다른 상태 머신은 단순한 것에서 다소 복잡한 것까지 다양합니다 (하나는 15 개 상태).통신 상태 머신은 더 많은 공동 – JeffV