RTOS와 임베디드 리눅스간의 반응속도 차이? 가 많이 나나요

alswn15951의 이미지

이직후 RTOS 보드를 이용해 실시간 모터 제어처리를 하는 프로젝트를 진행중인데...

문제는 제가 RTOS를 사용 안해봤습니다.. i.MX6 시리즈 YOCTO 임베디드 리눅스쪽 보드만 조금 개발해봤는데 RTOS 올라가는 보드가 싼것도 아니고 굳이 RTOS를 사용해야 하나 싶네요

더 큰 문제는 RTOS쪽 펌웨어를 제가 담당해야 되는데 RTOS를 써본적도 없고 arm도 처음 써봐서 되게 곤란하네요...

사용하는 보드도 개발 전용 보드가 아닌 다른 용도의 오픈소스 보드를 사용하는거라서 제어쪽 예시도 거의 없어서 정말 총체적 난국입니다...

RTOS가 올라가는 보드는 Cortex-M 시리즈 쓰는데 A 시리즈 보다 단가가 싼것도 아니고 해서 이쪽으로 계속 개발해야 되나 싶네요

푸념은 여기까지 하고 본론만 말하면

Cortex-M 시리즈 RTOS나 AP들어간 임베디드 리눅스나 별차이 없을것 같은데 RTOS의 큰 장점 같은게 있을까요...

jachin의 이미지

Cortex-M 계열 프로세서는 프로세서이지만, 마이크로컨트롤러에 가깝게 동작하게 하기 위해서 파이프라인도 3단계로 제한되고, 캐쉬메모리도 없으며, 내부 SRAM을 사용하여 동작하도록 만든 하바드 아키텍쳐 구조 프로세서입니다.

http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/CHDCHEAG.html 참조

인터럽트가 걸리면, 바로 해당 인터럽트 처리를 하며, 신뢰성있게 실시간 반응을 하기 위해 만들어진 프로세서입니다. 여기에 Linux 펌웨어를 올린다고 해도, 일반 리눅스 커널 동작과는 다르게 움직입니다.

만약 A 계열 프로세서로 모터나 슬라이드를 동작시키는 제품이 있다고 했을 때, (이를테면 버스 출입문이나 지하철 플랫폼 입출입 도어) 펌웨어 내부의 캐쉬구조나 펌웨어 자체의 결함으로 소프트락이 발생하는 경우, 동작이 쉽게 지연되거나, 잘못된 오동작을 일으킬 수도 있을 겁니다. 중간에 응급한 인터럽트를 처리해야 하는 경우 (슬라이드 도어에 사람이 끼어있을 경우), 긴급한 인터럽트임에도 캐쉬 메모리의 스레드 처리나 커널내의 다른 드라이버 인터럽트 처리에 지연이 생기면 사고로 이어지는 겁니다.

Cortex-M 계열 제품으로 SCADA 시스템이나 군용 무기체계에서 RTOS를 사용하는 이유는 그러한 응급한 인터럽트가 실시간으로 동작하는 것을 보장하면서, 날로 복잡해져가는 통신 체계와 운용 체계에 대응하기 위해 만들어지고 있는 것입니다.

라스코니의 이미지

리소스 경쟁(resource race, race condition)이 심하나 안심하나에 따라서 갈릴 것 같은 생각이 드네요.

RTOS 하면 떠 오르는게 low & constant interrupt latency 인데 이게 수십 us ~ 수백 us 이 정도거든요? 이 정도의 order로 문제가 생기는 시스템은 1초에 수 ~ 수십 km를 날아가는 미사일/로켓 등 매우 제한된 실시간 시스템에 국한이 됩니다. 대부분의 경우 밥솥이나 냉장고 등에는 이런 정도의 실시간성이 필요하지 않습니다.

그럼 뭐 때문에 RTOS를 쓰는가? Linux를 써도 되지 않을까? 라는 생각이 자연히 들게 되는 것 같네요.
제 생각에는 양쪽의 문화가 다른 것 같습니다. RTOS는 task/process synchronization이 매우 중요합니다. RTOS를 이용해 개발된 코드를 보면 세마포/IPC로 점철이 되어 있지요. 비싸고 저렴한 RTOS를 떠나서 대개 형태가 그렇습니다.

반면 Linux는 그냥 쓰레드 정도 만들어서 쓰는 정도이지요(물론 복잡한 처리는 커널에서 수행되고 있어서 사용자에게 보이지 않는 것 뿐이지만요). 대충 쓰레드가 돌아도 상관안하는 분위기? 뭐 그런 것 같습니다. 실제로 대충 디자인해도 얼추 돌아갑니다.

하지만 RTOS를 이용해서 대충 디자인해서 개발하면 반드시 응답없음으로 돌아오지요.

제 생각으로는 거의 대부분의 실시간 시스템은 Linux로도 잘 될거라고 봅니다. 단 엄청난 커널의 크기 때문에 작은 장치에 넣는 것이 어려울 뿐이지요.