소스코드리뷰(XXXVIII) 시리얼 통신속도를 따라가려면

시리얼 통신이라하면 이미 구시대적인 통신방식이라고 생각하기 쉽다. 랜이 있고 고속 통신네트워크가 있는데 굳이 시리얼 통신이라? 하지만 여러가지 이유에서 다시 시리얼 통신이 응용의 발을 넓히고 있다. 요새는 주로 시리얼 통신등의 고속 처리와 수치해석 등의 최적화에 업무 시간이 사용되고 있다.

시리얼 통신은 측정 장비등의 데이터 통신을 위해서 사용되는데 요새는 무선 통신, 즉 블루투스(Bluetooth, 사람이름에서 유래, 굳이 번역하자면 파란니)이 주로 사용된다. iPhone, Android 기기등이 블루투스를 사용할 수 있으므로 측정장치를 연결할 수 있으면 활용이 다양해 진다.

측정 데이터의 파형을 그리려면 ?

데이터 수신부, 데이터 저장부, 그래픽 처리부로 나누어 설계하는 것이 좋다. 다음은 VB.NET에서의 클래스를 가지고 예를 드는 것이다.

• 데이터 수신 --- SerialPort class를 사용
• 데이터 저장 --- ArrayList class를 응용
• 그래픽 처리 --- 수신 계기(SerialPort.DataReceived event)에 의해 저장된 데이터를 일정량을 모아서 그래픽처리를 하는 것이 낫다. 그러나 고속으로 데이터를 수신하는 경우에 비교적 그래픽처리가 무거운 경우에는 수신계기만으로 처리하기에는 부족한 점이 있다.
  

데이터 저장을 데이터베이스를 사용하여 SQL문, INSERT INTO를 구사하면 수신 속도(1000 Hz등)에 미치지 못하여 CPU사용율이 계속 100%로 올라갈 위험이 있다. 시스템의 데이터 성향을 고려해야 할 것이다. 메모리에서 저장을 처리하는 Collection(.NET ArrayList)를 사용하는 것이 단시간내에는 유효한 방법이다.

그래픽 처리에 부하가 걸리는 경우 데이터 수신 계기(DataReceived event)는 그래픽 처리가 다 끝나기 전에 다시 데이터를 수신해 버려서 그래픽 처리가 엉망이 되는 위험성이 있다. 무엇보다 문제점은 데이터 수신 중에 통신을 절단(Close)하게 되는 일이 생기기 마련인데, 제어선은 절단하게 되었어도 데이터는 계속 실타래(Thread)처리에 의해서 통지되어 버림으로 실시간 표시 제어가 불편하게 된다.

그럼에도 불구하고 이런 소량의 데이터를 받아주는 것으로 마쳐지면 다행이거니와 직접 테스트해 본 결과만으로 말한다면 Close 처리는 되지만 SerialPort.Close의 메소드 실행 이후에 제어가 다시 어플리케이션으로 돌아오지 않고 먹통이 되어 버린다는 문제가 생긴다. 이는 예외처리로도 잡을 수 없고 단지 제어가 되돌아 오지 않고 멈추어 버리기 때문에 프로그램이 응답하지 않는 문제와는 또다른 성격의 문제점이다. 여러가지 문헌을 조사하여 보았지만, 적절한 해결책은 발견되지 않았다. 아마도 문제점이 보고되지도 않은 것으로 보인다.

그러면 데이터 수신 중에 제어 커맨드를 보내서 데이터 송신을 멈추게 하고 절단(Close)한 경우에 생기는 VB.NET 프로그램의 먹통이 되는(흔히 Freeze) 현상을 대체하는 방법은 있을까?

SerialPort.DataReceived 통지를 사용하지 않고 주기적으로 타이머(Timer.Tick) 에 의하여 데이터를 감시하는 방식으로 회피할 수 있다. 처리문은 SerialPort.DataReceived 이벤트에서 하던  처리와 같다.

가장 높이 피어있는 무궁화

이번엔 플래시를 터뜨려서 찍은 무궁화

가까이서 보면 무궁화의 아름다움에 매혹될 것이다

크고 깨끗하고 순결한 무궁화는 멋진 꽃이다

화면 갱신 속도를 조절하려면?

화면이 갱신되는 속도가 빠르다고 해서 반드시 좋은 것은 아니다. 육안으로 감지할 수 있는 저속으로 화면 갱신을 처리해주는 것이 좋다. 경험적으로 말하면

1. 1000 msec --- 매우 느린 반응을 나타내기에 적합하다. 뭔가 일어나고 있다는 느낌은 줄수 있지만, 때로는 시스템이 정지한 것으로 보일 수 있는 긴 시간이다.
2. 750 msec --- 고속이 아닌 애니메이션 효과로 적합하다. 사용자에게 재촉하지 않는 느낌의 대기 상태를 표현하는데는 최적이다.
3. 500 msec --- 초당 두번의 갱신은 빠른 느낌을 주지만 통신 상태를 나타내는 것으로는 비교적 저속의 느낌을 준다.
4. 300 msec --- 초당 세번의 갱신은 저속이나 고속의 애매한 경계선에 놓여 있다고 할 수 있다. 빠른 느낌을 주기에는 느려 보이고, 느리다는 생각하기에는 빠르다.
5. 100 msec --- 초당 10번의 갱신은 고속 통신의 느낌을 주기에 충분하다.

 만일 1000 Hz의 속도로 통신이 발생한다면 화면 갱신은 1%의 비율로 줄여서 10 Hz 의 화면 갱신으로도 사용자는 충분히 고속으로 통신이 발생하고 있음을 감지할 수 있다.