RTOS 시스템 mbed os - thread 정리

우선 개념부터 잡고 가려고 한다. 나도 착각하고 있던 부분인데, RTOS가 (Real-time)이 들어간다고 해서 막 실시간으로 뿅뿅 되고 하는 그런 개념이 아니다. RTOS는 내가 원하는 시간 내에서 실행을 시키게 하는 것이 목적이다. 당장 뭔가를 자르는 공장이라면, 사람 손가락이 들어갔을 때, 손가락이 톱에 닿기 전에 멈추게 하는 것이 목적일 것이다.

 그런데, 내가 여유롭게 안마 의자에 앉아있는 상황에서, 반드시 안마의자를 작동시킴과 동시에 안마를 시작해야 하는 것은 아니다. 조금 늦게 작동하더라도 사용자에게 아주 큰 불이익이 있는 것은 아니다.(오히려, 스무스하게 작동되게 한다면 더 큰 편안함을 느낄 것이다.) 그런데 이 두 상황 모두 임베디드 시스템이고, RTOS를 쓸 것이다. 잠시 정리를 하자면 지금, RTOS를 시작하기 전에 왜 RTOS를 쓰는지에 대한 이유, 개념부터 잡고 가고 있다. 

 기존 OS : 반드시 어떤 시간 내에 해야 하는 것이 아님 / 사용할 수 있는 어플리케이션이 다수

    RTOS :  내가 원하는 시간 내에 모든 일이 처리되어야 함 / 하나의 어플리케이션만 사용 

 Read-time도 Hard/Soft Real Time으로 나뉘는데, 이는 방금 말한, 공장/안마의자의 차이와 비슷한 것이다. 어찌 되었든 간에 이번에는 Firmware와 OS를 쓰는 것의 차이를 분명하게 짚고 넘어가고자 한다.

아두이노로 어떤 작동을 수행하게 만들었다. AVR로 라인트레이서를 만들었다. ARM으로 드론을 만들었다. 전부 펌웨어를 개발한다고 지칭하기도 한다. 엄연한 의미에서 CPU의 모든 동작을 고려하고, 이 예외처리에 우선순위를 전부 매겨서 프로그램을 짜고 하는 것만 펌웨어라고 지칭하기도 한다.

 그래서 펌웨어를 개발할 때에는 모든 것을 고려해서 자원을 낭비하지 않도록 최적화를 아주 똑부러지게 해야 한다. 프로그래밍하는 개발자가 알.아.서. 오, 내가 들었을 때에는 끔찍해 보인다. 그래서 파일 관리, 테스크간의 우선순위 관리, Syntex Switching등 모든 것을 알아서 해 주는 녀석이 등장했다. OS(Operatin System)라고 한다. 물론 OS라 하면 윈도우 리눅스 맥 OS 이런 멋들어진 GUI를 먼저 생각하지만, 지금 임베디드 시스템을 말하고 있고, 앞서 말한 일반 OS도 내부에서 저런 처리를 해 주는 것은 마찬가지일 것이다.

 그럼, 우리는 OS에게 맡기고 편안해졌다. 정확히 말하자면 OS의 Scheduler에게 내 프로그램들을 어떻게 동작시킬지 부탁을 해 놓았다. 물론 편해졌다. 그런데 또 여기서 문제가 생긴다. OS의 Scheduler한테 시켰는데, 내가 원하는 대로 하질 않는다. 내가 원하는 순서대로 작동하지도 않고, 어 엄밀히 말하자면 내가 원하는 "시간"대로 움직이질 않는 상황이 생겼다. 오 무척 화가 날 것 같다. 편해지려고 OS한테 맡겼는데, 또 문제가 생겼다. 

 만약 OS없이 펌웨어로 직접 전부 관리해주고 있다는 상황이라면 이건 전부 뜯어고쳐야 하는 심각한 문제이다. 불행 중 다행히도 우리는 OS를 쓰고 있다. 그럼 할 일이 보다 적어진다. RTOS에 FreeRTOS도 있는데, 지금부터 이야기 할 것은 mbed OS이다. 또 다행인 것은 mbed OS는 C++로 구축을 잘 해놓아서 FreeRTOS보다 코드를 작성할 양이 압도적으로 적다! 오홍, 그럼 우리가 해야 할 일은 "시간,(타이밍)"을 고려해서 우리의 MCU가 어떤 기능을 잘 수행하도록 해주는 것이다. 

 결론적으로, 코딩을 할 것이고, thread를 써서 할 것이다. 우리가 쓰는 컴퓨터는 코어가 여러개 있다. 그래서 thread를 생각할 때 복잡하다. RTOS를 쓰는 지금 상황에서 우리는 코어가 하나다. 하나의 클럭만 돌고 있다. 그래서 모든 Thread들은 한 어플리케이션 위에서 생각하면 된다!!, 그것도 쉽지 않지만~

 thread라는 것이 무엇인가?? 한글로 하면 실이라고 한다. 1초마다 어떤 변수를 1씩 증가시키라고 했다. 그런데 이걸 하면서 이 변수가 10의 배수가 될 때마다 불을 깜빡이라고 했다. 둘 다 해주라고 했으므로 두가지 일이 일어날 것이다. thread가 둘인 것이다. (main문에서 무한 루프를 돌리고 그 안에 이것들을 때려넣는 것이 아니다. 그런 면에서 사실 예제가 조금 이상하기도 했다.) 이 두가지 일이 사이좋게 잘 작동할까?? 그러기 위해서는 1증가를 시켰으면 그 관련 thread는 이제 잠시 쉬어야 하고, 1초가 지났을 때 다시 1증가를 시켜줘야 한다. 이렇게 thread는 계속 상태를 변화시켜주어야 한다.

 문제는 10초가 되었을 때이다. 둘 다 일어나야 하는데 뭐가 먼저 일어날까? 만약 1증가가 먼저 되어버리면 그 변수가 더이상 10의 배수가 아니게 된다. 그래서 불은 깜빡이지 않을 것이다. 그런데 사실 모른다. 왜??? 생각을 해 보자. 이 변수를 가지고 두 thread가 경쟁에 들어갈 것이다. 그런데 이 둘 중에서 누가 이길지 모르기 때문이다.

 이렇게 공유 자원을 가지고 다른 두 일이 경쟁을 벌이는 상황이 생길 때 Thread를 우리가 잘 관리해 주어야 하는 것이다. thread()함수를 쓴다고 해서 무조건 thread인 것이 아니다. 이 함수는 단지 구현하기 위한 것일 뿐이다. 두가지 일 중에서 뭘 먼저 실행할 지 사용자가 정해주어야 한다. 우선순위를 주는 방식으로 할 수도 있고, 어떤 특정한 상황이라면 불을 깜빡이라고 할 수도 있다. RTOS를 쓴다면, 이런 것들을 고려한 프로그래밍을 해줘야 하는 것이다. 

예를 들어서 우리는 온도랑 습도를 측정하고 있다고 하자. 그런데 온도만 재고 습도는 재지 않고 있는 것을 발견했다. 허허, 이녀석 하고 뭐가 고장났는지 보았다. 기계는 거짓말을 하지 않는다. 내가 잘못해주고 있던 것이다. 온도를 재는 것, 습도를 재는 것, 다른 일이다. 그럼 다른