공돌이는 파닥파닥

Wipi 과제

프로그램이 어디에서 멈추는지 확인하기 위한 I/O코드들


학교에서 '모바일 프로그래밍'이란 수업을 듣고 있다.

그 '모바일'환경으로 잡은 것이 wipi 플랫폼인데
차마 일일히 핸드폰에서 돌릴 수 없으므로
에뮬레이터를 통해 결과를 확인하곤 한다.

그런데 정말인지....
디버깅 환경이 열악하다.

일단, '디버깅'이라고 할만한게 없다.
에뮬레이터에서 지원하지 않기 때문인데.
디버깅을 지원하는 에뮬레이터가 존재하지 않는다면, wipi는 '절대'사라지게 되리라 생각한다.
과제 수준의 어플리케이션을 디버깅하는데도 한참을 잡아 먹는데,
게임이나 다른 어플리케이션이었다면...
아아... 끔찍하다.
(KTF나 SK에서 제공하는 에뮬레이터는 아마도 지원하지 않을까 합니다.)

사실 이보다 더한 경우도 있었다.
필자는 학교과정과는 살짝 어긋나게 마이크로컨트롤러인 AVR시리즈에 관심이 많은데,
이 마이크로컨트롤러에 올리는 프로그램을 디버깅 하는 것이 좀 그렇다.
WinAVR과 AVRStudio라는 훌륭한 툴을 섞으면
멋진 디버그환경이 조성되는데(소스레벨 디버깅이 가능합니다. 사실 -_-; 어셈레벨에서 되는거지만요...)
문제는 정작 타겟시스템에 올렸는데 동작을 하지 않을 때다.
(거의 사소한 이유로 안되곤 합니다.)
이건 뭐... 안에서 어떻게 돌고 있는지 알 수가 없다.
(JTAG하나면 해결이 된다지요....)
그런 일을 겪고 나면 사용 중인 wipi에뮬레이터가
그나마 예외나 에러가 났을 때 콘솔창에 메시지를 찍어주는게 어딘가 싶다.
쭉! 뻗었을 때 어디에서 어떻게 멈추는지 알수라도 있으니
에러가 있는 범위를 좁힐 수 있기 때문이다.


필자가 실업전선에서 코드를 많이 짜보거나 한것은 아니지만,
이래저래 프로그램 코딩을 하다 보니, 첫 빌드에 성공하는 것은
전혀 힘든 일이 아니라고 생각한다. ( 그 뒤에 도사리고 있는 디버깅에 비한다면 )
물론 설계단계부터 짜임새 있게 진행된 경우 디버깅 시간은 획기적으로 단축되기 마련이지만
간단한 구조가 아닌 이상에야 버그는 어딘가에 존재하기 마련인데
좋은 디버깅 환경일 수록 빛을 발하는 순간이 이 때가 아닐까.
(요새 uC/OS-II라는 RTOS와 Application을 디버깅 하는데 툴의 도움을 많이 받고 있습니다.)

Comment +0