Message 기반 만들기

RTOS조차도 없는 Firmware에서는 각각의 기능 프로세스의 처리 시간을 적당히 잘 분배 해야 합니다. 

처리 시간이 긴 프로세스는 여러개로 쪼개야 하며, 특히 인터럽트 발생시 인터럽트 루틴에 긴 처리시간을 요구하는 코드를 넣으면 절대 안됩니다.  더욱이 간당간당한 처리시간을 요구한는 코드를 넣는 경우가 더욱 위험합니다. 왜냐하면 어쩔때는 잘 돌아가고 어쩔때는 에러를 발생시키는 경우가 발생할 수도 있으며 이러한 경우에는 디버깅이 상당히 힘들어 집니다.

처음부터 아예 인터럽트 루틴에서는 단순히 데이를 적당한 자료구조에 적재해놓던가, 해당 플래크를 set하는 수준 혹은 메시지를 던져주는 수준에서 마무리하는 것이 가장 좋습니다. 

만약 전체 시스템이 1초단위로 어떠한 처리가 끝나야 한다면, 각각의 프로세스들이 최대 처리되는 시간의 합이 1초를 넘어서는 안되며 50%~70% 정도가 적당하다고 생각합니다. 처리시간 측정은 특정한 GPIO를 이용하여 처리할 동안 set, 처리가 끝나면 reset하는 과정을 모든 프로세스에 적용시키고 scope로 측정하는 방법도 있습니다. 아니면 측정하는 firmware를 구현 하는 방법도 있겠네요.

아무튼 이러한 이유로 Message기반으로 프로세스를 처리하도록 하는 것은 괜찮은 아이디어 같아서 구현해 보았고 실전에서도 사용해보니 각각의 프로세스를 처리하는 데는 문제가 없었습니다.

*Message를 너무 자주 발생시키는 곳에는 적합하지 않습니다. Message 적재가 한정되어 있다보니 다 처리하기도 전에 overwrite 되는 경우도 발생할 수 있습니다. 

헤더파일입니다. 메시지 자체가 있습니다. 현재는 3개의 실질적인 메시지가 있네요. 여기서 MSG_NONE는 처리하지 않을 예정입니다. 그리고 메시지를 set하고 get하는 부분과 clear 시켜주는 함수가 있습니다. 

외부에서 메시지를 발생시키려면 set_message에 message 종류와 파라메타를 넣어주면 됩니다. 이렇게 쌓인 message들은 main 무한루프에서 들어오는 순서대로 처리할 예정입니다. 이제 실제 구현 코드를 보겠습니다.

message 는 총 30개까지로 정해놓았습니다. 알아서 필요한대로 늘려서 사용하면 됩니다. message 자료 구조는 전형적인 환형Queue 입니다.

위의 함수를 이용해서 메인 무한루프 코드를 보도록 하겠습니다. 지난번에 schedule을 계속해서 사용해보도록 하겠습니다. schedule을 사용하지 않는 경우에는 while 루프에 message_process를 직접 넣으면 됩니다. 아울러 message_process의 두개의 파라메타는 혹 직접 호출할 경우를 대비해서 미리만들어 놓은 것입니다. 앞으로도 이런식으로 두개의 파라메타는 습관적으로 들어갈 예정입니다.

특이 사항은 없습니다. 메인 무한루프에서는 메시지 큐를 확인하여 메시지가 있으면 계속해서 실행하면 됩니다. 메시지는 각각의 센서나 입력단에서 발생시키면 됩니다.