Xkobo for Mac OS X

2010.08.05 11:56 from programming

대학시절 동아리방에 덩그러니 놀고 있던 리눅스 머신이 한 대 있었다. 아마도 386수준의 PC에다가 리눅스 깔아놓고, 공부시킬 용도였던거 같은데, 사실 과제마감기간에 임박해, 서버실 자리잡기가 힘들 때 대신 활용되곤 했었지. 그러다 언젠가 부터, "귀여운 우주선게임"이라고 불리는 Xkobo라는 게임이 유행했고, 스코어나 하이레벨 경쟁이 붙기 시작했다. 

나도 처음에는 별 쓸데없는 게임이나 하고 있다며 혀를 끌끌찼지만, 그 단순해 보이는 게임의 매력에 빠져들까 생각하던 즈음, 모두가 "마의 23판"이라 부르는 공략불가의 레벨이 있다는 소식을 듣게되었다. 이 소식과 함께, "나라면 깰 수 있을거다"라는 근거없는 자신감이 있었고, 도전하고 말았다. 곧 "마의 23판"은 나에게 처음 공략당했고, 순식간에 "코보의 신"으로 칭송받게 되었지. 

곧 이 소식을 접한 경쟁자들도 도전했고, 며칠이 지나지 않아 "마의 23판"을 넘어서는 동지들이 늘어났다. 문제는 한동안 누구에게도 깨지지 않던 "마의 23판"이 한명에게 깨지는 순간, 봇물 터지듯 모두가 깨고 말았다는 거다. "안된다고 생각하던 일도, 누군가 이뤄낸(?)것을 알게 되면, 금방 되게 할 수 있다"는 걸 눈앞에서 경험한 순간이랄까? "할 수 있다"라는 자신감의 중요성. 훗.

어쨋든, 잠시나마 즐겼던 Xkobo의 여운을 잊지 못해, 해당 게임을 윈도우용으로 포팅하기로 맘먹었었다. X Window에 C로 작성된 게임을 Win32환경에 Delphi로 포팅했다. 지금생각해보면 정말 무식한 포팅이었다. 모든 C코드를 손수 Pascal코드로 번역한거니까. 

그게 98년쯤의 일이니 12년전 얘기구나....

그러다가, 얼마전에 Mac OS X용으로 포팅했다. 사실  Mac OS X에는 이미 X Window 시스템이 들어가 있기 때문에, 거의 그대로 컴파일하고 실행해서 즐길 수 있다. 하지만 원래 코드가 워낙 오래된지라, 요새의 Mac OS X에서 컴파일할때 호환이 되지 않는 부분이 있었고, 몇줄 수정하고 애플스크립트로 묶어서, 애플리케이션으로 만들어서 공개.


http://osxkobo.appspot.com/

이게 진정한 포팅이라고할 수 있지. 
Posted by hatemogi 트랙백 0 : 댓글 2

댓글을 달아 주세요

  1. addr | edit/del | reply donny 2010.08.05 13:36

    한국에서 반응이 저조하여 여기다 광고하는 거야? ㅎㅎ
    오.. 그런데 Wkobo가 Manual C-to-Pascal 이었던 거야? 대단하군!!!

  2. addr | edit/del | reply BT_비티 2010.08.06 09:32 신고

    진정한 포스팅 인정. 우리 과방에는 뿌요뿌요 대전이 벌어졌었다는... ㅋㅋ
    한번 간길은 두번 가기 쉬운 법이지. 암.


기분이 복잡하면 무제 노트를 펴고, 그냥 머리속의 이런 저런 생각들을 마음에 드는 펜으로 끄적여보곤 한다. 이래저래 편하게 적다보면 딱히 정리되는 것은 없더라도, 무언가 편해지는 느낌이 있어. 

오래간만에 내 블로그에 들렀다. 주인조차 들르지 않는 블로그라니, 누가 와서 들러보겠는가. 마지막 포스트가 구글코드잼 예선 통과에 관한 것이었구나. 결과를 안적었었네. 결과는 사실 창피하다. 

http://www.go-hero.net/jam/10/name/hatemogi

본선1라운드의 A, B, C중 한번이라도 1,000위 안에 들면 본선2라운드로 진출하는 것이었는데, 세번 모두 1,800위 정도의 저조한 성적을 기록하며 탈락했다. A, B, C 모두 참가하고도 (즉, 7시간 30분을 들이고도) 다 떨어지는 최악의 시나리오가 펼쳐졌달까? 세 번 모두 가장 쉬운문제만 풀 수 있었다. 나머지는 이해도 못한 문제가 많았다.  

아무튼 저렇게 떨어지고나니, 허탈감이라해야할지 뭐랄지 모를 묘한 부정적 감정에 휩싸여버렸다. 첫 도전에 쉽지 않을거라 생각은 했지만, 그래도 본선2라운드는 진출 할 수 있을거라 내심 기대했었는데 말이다. 

대학때, 자료구조 수업을 들었을 때의 느낌이랄까? 첫 전공수업다운 전공수업이었는데, 쉽게 적응하지 못했을 때의 당혹감과 비슷하다. 내가 좀 한다고 자만하던 분야에서의 코깨짐? ㅋ

따지고보면 뭐 세계 4,000위쯤 되니, 그렇게 형편없는 것은 아니라고 위안해보지만, 난 이해할 수도 없는 문제들을 10~20분에 다 풀어내는 애들이 있다는 사실을 보면 주눅이 드는 기분은 피할 수 없다. 

내년에 또 도전해 봐야지 뭐. 그냥 무작정 재도전이 아니라, 알고리즘 책이라도 한권 공부하면서 준비하자구.

Posted by hatemogi 트랙백 0 : 댓글 3

댓글을 달아 주세요

  1. addr | edit/del | reply 최동규 2010.08.01 21:47

    세계 4,000 위라.. 훌륭하신데요.^~^

    • addr | edit/del hatemogi 2010.08.05 11:43 신고

      ㅎㅎㅎ. 아무도 기억하지 않을 순위죠. 현실직시하고 열심히 하려구요. ㅋ

  2. addr | edit/del | reply goodchoi 2010.08.16 04:31

    아 ㅋㅋ 대현님, 제가 기억합니다. 그리고 저 말고도 최소 몇 몇 분은 기억하실걸요 ㅎ

TLS on iPhone

2010.03.24 17:22 from programming
아이폰 응용프로그램으로부터 서버와 네트워크 통신하는 내용을 암호화 하기 위해 TLS(Transport Layer Security)를 쓰는 방법을 정리합니다. 

HTTPS

HTTP통신의 경우에는 NSURLRequest를 사용할때 https 스킴을 사용하면 자체적으로 HTTPS를 사용하므로, 별다른 설정 없이 보안설정이 가능합니다. 일반 HTTP통신과 동일한 방식으로 NSURLConnection 객체를 활용하여 HTTPS를 사용할 수 있습니다.

서버측에서 비공인 인증서(eg. self-signed certificate)를 경우에는, 아래의 delegate method를 구현해서 처리 가능합니다.

- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace;
- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;

TLS socket

하지만, HTTP통신이 아닌, 일반 소켓 통신의 경우 얘기가 조금 다릅니다. NSStream 객체로 만들어 소켓통신을 할 수 있습니다만, SSL통신을 하기위한 옵션이 있습니다. NSStream을 만들고 스트림을 open하기 전에 아래의 속성을 설정하고 나서, 스트림을 열면, 열리자 마자 TLS handshaking을 진행합니다. 

[stream setProperty:NSStreamSocketSecurityLevelTLSv1 forKey:NSStreamSocketSecurityLevelKey];

하지만, 이경우에 비공인 인증서는 사용할 수 없습니다. 어떻게 하면 비공인 서버인증서로 TLS통신을 할 수 있을까 조금 더 자료를 찾아본 결과, CoreFoundation쪽을 직접 건드리는 방법이 있었습니다. CFReadStream과 CFWriteStream에 속성을 설정할 수 있는 함수가 있고, 아래의 코드처럼 kCFStreamSSLValidatesCertificateChain속성을 NO로 설정해서, 서버인증서 검증과정을 생략할 수 있습니다.

NSDictionary *settings = [NSDictionary dictionaryWithObjectsAndKeys:
 [NSNumber numberWithBool:NO], kCFStreamSSLValidatesCertificateChain,
  kCFStreamSocketSecurityLevelTLSv1, kCFStreamSSLLevel,
 nil];
CFReadStreamSetProperty(readStream, kCFStreamPropertySSLSettings, (CFTypeRef)settings);
CFWriteStreamSetProperty(writeStream, kCFStreamPropertySSLSettings, (CFTypeRef)settings);

위의 설정후에 CFReadStream과 CFWriteStream을 각각 NSInputStream과 NSOutputStream으로 바꾸어 사용하면, open후 TLS handshaking이 진행된 채로 데이터를 주고 받을 수 있습니다.

 
Posted by hatemogi 트랙백 0 : 댓글 0

댓글을 달아 주세요

EventMachine

EventMachine은 Ruby, Java, 그리고 C++을 위한 고성능 네트웍 I/O라이브러리이다. 최근 네트웍서버를 하나 만들게 되었는데, 프로토타입 개발과 성능테스트 모듈을 EventMachine으로 개발했다. 예전에는 Ruby용 라이브러리라고만 생각했는데, 살펴보니 Java나 C++환경에서도 쓸 수 있을뿐더러 (JRuby가 아니고서야 누가 쓸까 궁금하긴 하지만 말이다) 보면 볼 수록 잘만들었다는 생각이 들었다.

실제 서버는 사내의 자체개발 프레임워크를 이용해 C로 개발을 완료하고 성능테스트를 돌리려는 시점이었다.  EventMachine을 써서 개발한 루비 프로세스를 17대의 서버에 얹어놓고, 한꺼번에 접속해서 부하를 주려는데, 각각의 루비프로세스가 TCP커넥션이 1024개 근처가 되면 죽어나가는 상황 발생. 당연이 Max Open File Descriptor문제이리라 생각하고, 17대의 서버에서  ulimit을 모두 올려주었다. soft/hard limit을 모두 올려놓고 다시 테스트를 하는데, 또다시 1024개 근처에서 루비프로세스는 죽고 말았다. 

성능테스트 모듈자체가 중요한 상황이 아니었기때문에, 해당 문제를 해결하는 일은 접어두고, 성능테스트 자체에 집중하기로 했다. 결국 각각의 서버에서 다수의 루비프로세스를 실행해서 목표서버에 무식하게 많은 커넥션을 열고 트래픽을 걸어서 테스트를 완료했다. 

Ruby의 select문제

그러고 며칠 후, 아무리 생각해도, 루비 프로세스가 죽어나간 점이 찜찜해서, 여유시간에 해당 문제를 파고들었다. 찾아낸 결과 자료는 의외로 가까운 곳에 있었다. eventmachine패키지안에 포함된 EPOLL이라는 텍스트 문서에 아주 자세하게 설명되어있던 것. 

select함수는 해당되는 descriptor가 수백개가 넘어가면 성능저하가 매우 진다고 하는데, 게다가 루비에서는 select를 사용할 수 있는 디스크립터 수가 1024개로 제한되어있던 것. 우선 루비에서 하드코딩으로 이 숫자가 제한되어 있는 점은 그러려니 한다. 어차피 수백개 넘어가면 지나친 성능 저하로 실용성이 매우 적기 때문에 1024개도 너무 많다고 생각하니까 말이다. 하지만, 문제는, 믿었던 EventMachine인데, 난 이 친구가 당연히 epoll/kqueue를 기본으로 사용한다고 믿어 의심치 않았던 것.  


epoll, kqueue

EventMachine의 기본값은 그냥 일반 select함수를 사용하는 것이었다. 응? 설치할 때 컴파일하면서 시스템별로 사용할 수 있는 함수 사용하는 거 아니었어? 당연히 내 Mac에서는 kqueue를 쓰고, Linux환경에서는 epoll써줘야하는 거 아니야? 결과적으로, 현재버전까지(0.12.10) 아직은 아니었다. 

EM.run 블럭을 실행하기전에 

EM.epoll
EM.kqueue
EM.run {
   ...
}

를 실행해 주어야, 해당 기능을 쓸 수 있는 환경에서 작동을 하며, 그렇지 않다면 그냥 select를 쓰게 되는 것.  두 함수는 해당 기능을 쓸 수 없는 환경에서는 무시되므로 환경 생각하지 않고 호출해주어도 되겠다. 기본값이 일반 select를 쓰게해놓은 이유는 뭘까? 

아무튼, EventMachine을 쓰면서 다수의 연결을 유지해야할 필요가 있다면, 위 메소드들을 꼭 호출해 놓고 사용해야할듯 하다.  




Posted by hatemogi 트랙백 0 : 댓글 1

댓글을 달아 주세요

  1. addr | edit/del | reply hatemogi 2010.07.13 12:25 신고

    추후에 알게된 내용: EventMachine에 EPOLL, KQUEUE 기능이 추가되기 전 버전을 사용한 코드들에 대해, 안전한(!) 호환성을 제공하기 위해, 기본은 select방식으로 남겨두었다 함.

드리프트 제어 유닛

2009.08.24 11:56 from programming
장난감 R/C카 제어

최근 몰입하고있는 개인 프로젝트가 있습니다. "소프트웨어 개발자의 하드웨어 개발기"를 쓰게 된 이유이자, 목표 결과물은 오래전의 꿈과 관계되어 있습니다. 사실 대학시절에 완성했어야할 프로젝트인데 10여년이 지난 이제서야하고 있네요. 어린시절 꿈쫓기의 하나입니다.

만들고 있는 것은 맥북(or 아이팟 터치)로 R/C 자동차를 제어하는 시스템입니다. 이 프로젝트를 핑계로, 입문용 R/C 자동차 세트도 하나 샀습니다. 어릴적에 그토록 갖고 싶었던 장난감이죠. (사실은 이게 사고싶어서 이런저런 핑계를 만든건지도 모릅니다)

DSC_6174

임베디드 시스템을 만들어 넣어서, MacBook이나 iPod Touch에 개발해 넣은 소프트웨어로 저 사진의 장난감 차량을 제어하는 것입니다. 

컴퓨터 -> 무선 통신 -> 임베디드 시스템 -> R/C 자동차

이런 제어 흐름인데요, 사실 임베디드 시스템이 가장 약한부분이자, 관심부분입니다. 이번 기회를 통해서 어느정도 경험이 쌓이면, 여기에 간단한 OS를 얹는다거나, 루비같은 언어의 인터프리터를 얹는다거나해서 더 어릴쩍의 꿈을 이뤄볼 수도 있겠다는 야망이 불타 오릅니다. 흐흐, 김칫국물 마구 마시고 있습니다.


학창시절에 했어야할...

사실 이 구성은 대학시절에 구현했던 내용의 연장선 위에 있습니다. 초기 모델은 대학 신입생 시절에 전시회에 출품한 프로그램이었습니다. 당시에는 정말 애들용 R/C를 PC의 패러럴 포트에 연결한 회로를 이용해서 제어했었지요. 단순히 키보드로 R/C카를 제어한 간단한 예제였습니다만, 관람객(?)들은 키보드를 눌렀는데 실제 장난감이 움직인다며 신기해해서 반응이 좋았습니다. 

이어서, 제대로된 R/C 차량을 이용해서, 차량동역학 시뮬레이션을 해보고 싶었습니다만, 각종 미적분 수학식의 무게에 압도당해 완성하지 못했던 아쉬움이 남아있습니다. 다시 한번 기회를 잡아 인공지능 수업때에 과제프로젝트로 구현하려 했었으나, 프로젝트 상담중에 교수님과의 상담중에 방향이 바뀌어 결국 남들 다하는 시시한 오목 프로그램 만들었었습니다. 결국 그렇게 시간은 가고, 그냥 졸업해버렸네요.

당시에는 자동차 시뮬레이션 게임도 지금보다는 사실성(?)이 떨어지던 시점이었기 때문에, 계속 파고들었으면, 그럴싸한 자동차 시뮬레이션 소프트웨어를 흉내내볼 수 있었을지도 모르겠습니다만, 지금은 아무리 잘만들어봐도, 요새의 레이싱 게임만큼 만들기는 절대 무리겠지요. 대신에 공개된 레이싱 게임엔진을 찾아다 활용해 볼 수도 있겠네요. 

어쨌건, 차량제어 시뮬레이션을 저 1/10 스케일의 폭스바겐으로 보여줄 수 있다는 가정하에, 이런저런 프로그램을 만들어 볼 수 있겠습니다. 


드리프트 놀이

사진의 저 차량은 온로드(포장도로) 주행용 4륜구동 차량인데, 타이어를 드리프트용으로 교체해서 달았습니다. 액션영화에서 빠지지 않는 자동차 추격신의 하일라이트는 차량간 총격씬과, 골목길에서의 드리프트씬 아닐까요? 주인공의 차량은 아찔하게 사고를 피해가며, 골목길을 빠져나와 큰길로 접어들며 요란한 타이어 마찰음과 함께 카운터 스티어링과 함께 드리프트를 선보이죠. 

아래 사진은 실제 드리프트 경주용 차량의 사진입니다.




드리프트 관련 자료를 찾아보다가, 드리프트의 원리와 방법들을 살펴보게 됐는데, 역시 드리프트가 쉬운게 아니더군요. 덕분에 왜 가능 방향과 반대로 카운터스티어링을 걸어주는지도 알게됐습니다. 

드리프트의 기본은 "뒷바퀴의 오버스티어링을 활용해서 차량 주행을 컨트롤"하는 것이더군요. 뒷바퀴의 오버스티어링을 위해서는 차량이 4륜구동이거나 후륜구동이어야합니다. 국내 대부분의 세단차량은 전륜구동이므로, 일반 차량으로 드리프트를 해보기 어렵다는 판단에 이를 수 있습니다. 전륜구동 차량은 오히려 앞바퀴의 언더스티어링 현상이 발생하기 쉽습니다. 

R/C차량의 경우 후륜구동 또는 4륜구동이 대부분인데, 2륜구동 차량으로는 드리프트를 제어하기 어렵기때문에 대부분 4륜구동 차량으로 드리프트 놀이(?)를 한다고 합니다. 4륜구동 차체를 준비해서 타이어만 미끄러지기 쉬운 드리프트 타이어로 교체해도 어느정도의 드리프트는 구사할 수 있습니다.

문제는 이 드리프트 기술을 활용하기 위해서는 뒷바퀴 오버스티어를 만회(?)할 수 있는 카운터스티어링이 적절히 필요하다는 겁니다. (위 사진을 보면 차량은 좌측으로 회전중이지만, 바퀴는 오른쪽을 향하고 있는 것을 볼 수 있습니다. 아래 그림은 반대) 



뒷바퀴가 오버스티어링 되는 상황을 그냥 내버려두면 차체가 계속 스핀이 걸려서 휙 돌아버리게 되는데, 이를 막기 위해, 접지력이 남아있는 앞바퀴의 방향을 회전반대편으로 조절하여, 차체의 회전을 막는 것입니다. 게다가, 속도가 어느정도 줄어서 다시 뒷바퀴의 오버스티어링이 끝나갈 시점에는 다시 카운터스티어링을 풀어줘야, 다시 반대편으로 급회전하게 되는 현상을 막을 수 있습니다. (오락실에서 레이싱 게임할 때, 흔히 겪는 현상이죠. 코너를 돈다고 심하게 핸들을 꺾었다가, 미끌어지기 시작해서 반대로 꺾다보면, 조금 제대로 가는 듯 싶다가 다시 반대쪽 벽을 들이받는 현상이죠)


즉, 적절한 드리프트 코너웍을 위해서는, B시점에 핸들을 반대쪽으로 틀어서 카운터 스티어링을 걸고, D시점에는 정상 스티어링으로 풀어줘야 원하는대로 코너를 빠져나올 수 있는 것입니다.


드리프트 컨트롤 유닛

이 기술을 구사하려면 많은 연습이 필요한것 같습니다. 순간적인 반응도 중요할테구요. 여기서 만들 임베디드 시스템의 응용 방법이 떠올랐습니다. 임베디드 시스템은 현재의 바퀴 회전각과 전후진 추진력을 알고 있으니, 현 차체의 움직임을 판단할 수 있다면 (즉, 오버스티어링 현상을 감지할 수 있다면) 자동으로 카운터스티어링을 걸어줄 수 있을거라는 생각이 들었습니다. 즉, 스핀현상을 막아서, 대충의 손기술로도 드리프트 놀이를 해볼 수 있지않을까 합니다. 다시말하면, 실제 차량에 탑재되는 차량 주행안전시스템(ESC등으로 불리는 옵션들)의 한 보기를 구현해볼 수 있다는 겁니다. (이거 찾아보다가 ABS의 원리까지 파악하게 됐습니다.)

더 흥미로웠던 점은, 이렇게 구현하려는 시스템이, 실제 R/C계에 상용화된 상품이 있다는 점이었습니다. 아래는 해당 제품을 판매하는 HPI사의 홍보 동영상입니다. 각각 해당기능을 켰을때와 껐을때의 시범 동영상이 있습니다. 물론 홍보용이니까 조금 과장된 면은 없지 않겠습니다만, 적절한 자동 카운터스티어링으로 스핀을 막아 안정된 드리프트 주행을 보여줍니다.   



제품의 연결선을 보아하니, 가속도 센서 값을 읽어 순간적인 회전이 발생하면 오버스티어링 상황으로 간주해서 카운터 스티어링을 걸어주는 방식으로 구현한것 같습니다. 간단하게는 이정도로 드리프트를 돕는 유닛을 만들 수 있겠구요, 나아가서는 가속/감속 상황까지 판단해서 더 나은 수준으로 구현해 볼 수도 있을 것 같습니다. 

그 외의 재미난 응용사례도 있으면 좋겠습니다. 이 결과물은, 10월달에 열리는 회사 개발자 컨퍼런스에 출품할 예정입니다.

====================================
인용자료: hpiracing.com, drivingfast.net

Posted by hatemogi 트랙백 0 : 댓글 8

댓글을 달아 주세요

  1. addr | edit/del | reply donny 2009.08.24 14:44

    드디어 어릴적 로망을 이루는 것인가?
    게다가 골프GTI는 지금도(물론 실물) 갖고 싶은 아이템인걸?

    갤럭시버기 한 대면 영혼을 팔 수 있을 것 같은 시절이 있었지ㅋㅋ

    • addr | edit/del hatemogi 2009.08.24 20:22 신고

      캬, 추억의 이름 갤럭시 버기... 정말 갖고 싶었는데... 아직도 그 모습이 생생해...

  2. addr | edit/del | reply BT_비티 2009.08.25 09:33 신고

    열라 짱 멋있음! 잘 모르는 분야라 더 대단해 보이구...
    카운터 스티어링은 애니메이션 Car 에서 본 기억이 나네.

    • addr | edit/del hatemogi 2009.08.26 10:29 신고

      오, 비티형, 잘지내죠? 귀국후 한번 보기가 힘들군요~ ㅋㅋ 저도 이제 현실(?)에 적응중.

  3. addr | edit/del | reply 은영 2009.08.27 15:32

    어렵다.... ㅎㅎ 신기신기.ㅎㅎ

  4. addr | edit/del | reply donny 2009.09.07 21:20

    어여 진도 좀 나가바바~

    • addr | edit/del hatemogi 2009.09.11 16:09 신고

      최근 장난감 말고, 실제 차에 관심이 잠시 쏠려서... 주말부터 다시 시작해야겠다. ㅋㅋ. 복직후 진행속도가 영 느려. 이젠 근무시간에 작업할 수 없으니...

첫 회로 구성 완료

2009.08.23 21:45 from programming
"소프트웨어 개발자의 하드웨어 개발기" 두번째 글입니다.

ARM Cortex M3 기반의 LM3S8962 개발보드에 블루트스 모듈, 3차원 가속도 센서 모듈을 연결하는데 성공했습니다. 전원공급과 배선 납땜조차 어떻게 해야하는지 모르는 상황에서 이래저래 하다보니 기대이상 잘 됐습니다. PWM 생성해서 서보모터 제어하는데에도 성공했습니다. 

DSC_6172

완성한 1차 보드의 모습. 맨 왼쪽은 JTAG 인터페이스, 가운데가 LM3S8962개발보드, 맨 우측이 블루트스 통신 모듈, 그 아래가 3차원 가속도 센서입니다. 기판 아래쪽에는 전원 공급과 서보모터를 연결하는 핀을 배치했습니다. 

하나하나 직접 만들려면 꽤나 어려운 일일텐데, 고맙게도 모듈화가 너무 잘 되어있어서, 필요한 모듈을 사다가 연결만 하면 되는 수준이었습니다. 이제 납땜은 일시 중단하고, 소프트웨어 개발을 본격적으로 해봐야겠습니다.
 
(저 보드는 프로토타입이랍시고 대강대강 만들었는데, 한번 하고 나니, 다시 하고 싶지는 않아서, 그냥 저걸로 그냥쓸까도 생각중입니다. 아마도 이걸로 끝나지는 않겠지만요)

여기까지 만들면서 어리석은 궁금증이 많았는데, 이래저래 찾아보고, 또 가까운 전문가(!)들에게 물어봐가며 해결했습니다. 제가 궁금했던 부분과 그 해결사항을 나름대로 적어봅니다. (학창시절이었다면, 자료 찾아보기도 쉽지 않았을텐데, 요새는 위키페디아에 이런정보들도 아주 잘 나와있더군요. 위키페디아 덕을 톡톡히 보고 있습니다. 이하는 제멋대로 이해한 내용이며, 정확한 내용을 위해서는 위키페디아를 보시는게 좋을것 같습니다) 

Q. 서보모터를 제어하기 위해서는 PWM (Pulse-Width Modulation)방식을 쓴다고 하는데, 대체 PWM이 무엇인가?
A. 1과0의 값을 넣어주는 주기와 길이에 따라 그 중간값을 표현하는 방식입니다.


위 그림으로부터 단순하게 이해하면, T주기 내에서 Ymax로 표현된 값이 지속된 시간 DT만큼의 비율로 표현 값을 이해할 수 있습니다. 예를들어 D.T가 T의 절반이라면 0.5로 해석하고, T와 같다면 1.0, 계속 Ymin이라면 0.0이라고 이해할 수 있는 것입니다.

제가 구매한 서보모터의 사양을 보면, 20ms주기 T에서, 1.5ms동안 High신호를 주고, 나머지를 Low로 주면 중립위치를 지키고, 1.0ms ~ 2.0ms 범위에서 High값을 주면 해당 값에 맞게 서보모터의 각도가 변화합니다.  즉, 20ms중에 앞부분 일부만을 사용해서 결과값을 사용하는 것이죠.

Q. 회로도들을 보면 캐퍼시터를 끼워넣는 곳이 많은데, 캐퍼시터의 역할은?
A. 전류를 안정화합니다. 

캐퍼시터의 역할이 여러가지 있는것 같은데, 제가 본 회로도에서의 역할은 전류흐름 안정화였습니다. 각종 대학서적을 봐도, 캐퍼시터의 종류와 특성은 잘 나와있으나, 왜 쓰는지에 대한 얘기를 찾기 어려웠습니다. 나와있어도, 저로서는 이해하기 어려웠습니다만, 결국 이해한 내용은 매우 간단합니다. 소프트웨어쪽으로 치자면 버퍼링입니다. 버퍼사이즈가 너무 적으면, 중간중간 데이터가 끊기는 상황이 생길 것이고, 사이즈가 너무 크면, 버퍼링하는 시간이 길어지겠죠. 적절한 크기에 맞는 캐퍼시터를 택하는것이 적절한 버퍼사이즈 정하는 것과 비슷한 문제인 것 같았습니다. 

DC전원을 공급하더라도, 그때그때 상황에 따라 전류가 튈 수 있는데, 이로 인한 오동작을 막기 위해 캐퍼시터를 중간에 병렬로 끼워주면, 안정화를 돕는 것 같습니다. 

Q. 서보모터를 제어하기위해서는 4.8V~6V사이의 전압을 공급해야하는데, MPU에서 나오는 PWM신호(아마도 3.3V)를 공급해서도 제어할 수 있는가?
A. 연결해보니 잘됩니다.

LM3S8962보드는 공급전압이 3.3V입니다. 각종 출력핀의 전압도 3.3V이지 않을까 생각되는데요, (지금생각해보니 측정해보면 되는군요ㅠ.ㅠ), 그렇다면, PWM출력신호도. 3.3V일 가능성이 높았습니다. 이 신호를 그대로 써도 서보모터가 정상 작동할지가 궁금했었습니다. 자료도 찾아보고, 주변의 전문가(!)들에게 물어보니, 아마도 될거 같으니, 한번 연결해 보라는 답변을 들었습니다. 

찾아보니, 이런 디지틀 입출력값을 TTL(Transistor-Transistor Logic)방식이라고 하는데, 0V~5V의 범위에서 0V~0.8V로 연결되면 Low(0), 2.2V~5.0V로 연결되면 High(1)로 나누어 판단하는 기준이었습니다. 즉, 만약 3.3V로 High신호가 나간다고 하더라도, 5V TTL기준에서 2.2V이상의 기준에 걸리기 때문에, 통신에는 문제가 없게 되는거죠. 


이 정도가 이제까지 가장 궁금했던 내용인데, 오늘 프로토타입 보드를 완성하면서 모두 해결되었습니다. 이렇게 저렇게 다 수가 생기는군요. 


-- Special Thanks to 도니형 & 근용군

Posted by hatemogi 트랙백 0 : 댓글 5

댓글을 달아 주세요

  1. addr | edit/del | reply donny 2009.08.23 23:19

    브라보~~~~!!
    블루투스통신 모듈을 연결한 것을 보니... 리모콘은 아이폰(터치)인가?

    • addr | edit/del hatemogi 2009.08.24 01:18 신고

      그렇지. 형이, UART이상은 엄두도 못내던 내게, 블루투스 가능성을 열어준게지. 이정도까지 됐으면, 이제 나머지 플랫폼은 자유자재일듯.

  2. addr | edit/del | reply donny 2009.08.24 12:24

    근데 블루투스가 송수신거리가 RC카 무선 송수신거리보다 많이 짧을 듯한데... 그게 좀 걱정이군 ^^;
    아무튼 도전 정신이 대단해.. 나도 뭔가 해보고 싶은 충동이 불끈불끈하구만 ㅋ

    • addr | edit/del hatemogi 2009.08.24 14:03 신고

      날카로운 지적이야. 블루투스 통신거리를 알아봤는데, 클래스3개로 나누더라고.

      클래스1: 약100미터 거리 통신
      클래스2: 약10미터 통신
      클래스3: 아주 짧은거리라 거의 안쓰임.

      대부분, 노트북이나 PDA등의 장비의 블루투스는 클래스2라고 하더군. 일단 모듈은 클래스1 모듈을 사서, 충분한 거리인데, 문제는 아이폰이나 랩탑의 블루투스가 클래스2일거라는거.

      대신 거리가 부족하면 클래스1의 USB 블루투스 모듈을 사서 꽂으면 해결은 할 수 있을거 같아.

  3. addr | edit/del | reply 동완짱 2009.08.29 09:30

    이제 본격적으로 이직하시는건가? -_-;;;;

"소프트웨어 개발자의 하드웨어 개발기"의 첫 글을 씁니다. 하드웨어 개발에 대한 지식도 무식이 전부이고, 관련해 받은 교육이라고는 고등학교 물리시간에 배운 것이 전부인지라, 모든게 까마득합니다만, 어설프게나마 기록으로 남겨보려 합니다. 누군가에게는 도움이 될지도 모르죠...

임베디드 시스템을 위한 MPU보드라는 걸 구할 수 있더군요. 각종 마이크로프로세서와 그에 연결한 메모리와 플래쉬, I/O모듈등을 함께 자그마한 시스템 보드를 묶어서 파는데다, 가격도 저렴하고, 기본적인 시스템이 갖춰져 있어서, 소프트웨어만 얹으면 간단한 임베디드 시스템을 만들 수 있게 말이죠. 학창시절에 관심을 두려할 때는, 다 따로 사서 만들어야하는 줄 알았습니다. 

CPU 벤더도 다양하고 모델도 다양하지만, 일단 ARM쪽을 알아봤습니다. 임베디드 하면 ARM프로세서가 먼저 떠오르더라구요. 많이 쓰이는 이유가 있겠지 싶었습니다. 국내 모 디바이스 쇼핑몰에서 찾아보니, ARM의 마이크로프로세서를 사용한 임베디드 개발보드가 여러개 보였습니다. 그중에는 ARM v7아키넥쳐 기반의 것이 가장 많은 것 같았고, 나름 신형인 ARM Cortex M3 아키텍쳐의 임베디드 개발보드가 눈에 띄었습니다. 

소프트웨어도 그렇지만, 좀 새로운거 쓰려고보면 이런저런 환경이 걸리는 것들이 많아서, 편하게 가려면 "많이 쓰이는" 녀석을 택하는게 최선이죠. 하지만, 뭔가 좀 새로 하려다 보면 아무래도, 신기술(?)에 끌려서, 고생을 사서하곤 합니다. 어차피 목표결과물을 내기 위한 여유시간도 많이 있겠다, 과감히 Cortex M3보드를 선택했습니다. 

그렇게 구매한 MPU보드는, Texas Instruments사가 인수한 루니너리 마이크로사의 LM3S8962를 가져다 만든 위드로봇의 myCortex-LM8962입니다. (텍사스 인스트루먼트는 어디서 들었는지 꽤 낯익은 회사명이었습니다) 이 개발 보드는 PWM제어 모듈도 포함되어 있어서 제가 원하는 목표결과물에 쉽게 접근할 수 있지 않을까 기대해봅니다.  



위의 보드의 은색 육면체가 이더넷 포트입니다. 보드 전체가 자그마하 하죠. 

저 보드에 전원공급이며, 신호선 연결은 어떻게 할지도 막막하지만, 일단 소프트웨어를 어떻게 얹을지가 막막합니다. 좀 찾아보니, 저 보드에 소프트웨어를 설치하는 방법은 여러가지가 있지만, 위드로봇사에서 판매하는 Stellaris-JTAG 보드를 사용해서 개발&설치하는 방법이 잘 나와있었습니다. (JTAG이 뭔지도 처음 들어보는 용어입니다. ㅠ.ㅠ 대충 이해한 바로는, 임베디드 하드웨어의 소프트웨어 설치나 디버깅에 사용되는 표준 인터페이스쯤 되나봅니다.) 우선 하드웨어 디버깅이 된다는 말에, 해당 보드도 같이 구매했습니다.




역시 비슷하게 작은 크기의 보드입니다. 저기의 USB포트를 PC와 연결하고, JTAG인터페이스를 개발보드에 연결하면, PC로부터 소프트웨어를 설치하고, 디버깅도 할 수 있습니다. 매뉴얼에 개발 방법이 잘 나와있습니다만, 한가지 아쉬운 점이 있었습니다. 각종 소프트웨어 드라이버나 개발 방법이 Windows기준으로 되어있다는겁니다. 이거 하겠다고, VM띄워서 개발하기도 깝깝하고, 그냥 맥에서 개발하는 방법이 없을까 찾아봤습니다. 이래저래 해보니, 다행히 Mac OS X에서도 개발이 가능하더군요. 

1. 하드웨어 연결

위의 두 하드웨어를 연결해서 MacBook Pro에 연결하면 다음과 같이 USB하드웨어가 잡힙니다. 


별다른 추가작업 없이 "Stellaris Evaluation Board"라고 잡혀줍니다. 고맙기 그지 없습니다. 

2. 컴파일러

OS X에서 사용할 수 있는 무료 ARM 크로스 컴파일러는 GNUARM과, yagarto가 있습니다. 이 중, Cortex M3를 지원하는 컴파일러는 yagarto뿐입니다. 바이너리를 받아서 /usr/local/yagarto에 설치했습니다.

3. OCD (On-Chip Debugger) 

JTAG인터페이스를 통해서 디버깅을 할때 쓰는 디버거입니다. 역시 무료버전으로 OpenOCD라는 소프트웨어가 있습니다. 이 소프트웨어는 OS X버전이 따로 있어서 별 문제없이 설치 가능합니다. 이 프로그램이 GDB와 연동해서 하드웨어에 소프트웨어를 얹을 수 있고, 얹은 소프트웨어를 디버깅할 수 있게도 해줍니다. openocd-ftd2xx로 USB에 잡힌 Stellaris Evaluation Board와 연결해서 작업할 수 있습니다. 따로 드라이버를 깔면 Virtual COM Port도 잡을 수 있을 것 같은데, 해당 드라이버가 아직 OS X Leopard까지만 지원하는 것 같습니다. (Snow Leopard 개발판을 먼저 쓰고 있는게 이럴때도 걸림돌이 되어주는군요) 일단 저는 Virtual COM Port가 필요없는 상황입니다.

OpenOCD가 최신버전이 0.2.0인데, 명령어가 조금 달라서, 매뉴얼을 보고 좀 손봐야할 부분이 있습니다. OpenOCD가 설치된 디렉토리를 뒤져보면  lm3s8962.cfg도 구할 수 있고, 인터페이스 설정파일도 찾아서 그대로 쓸 수 있습니다.


4. 통합개발환경 (IDE)

상용제품으로 CrossWorks for ARM이라는 아주 훌륭해보이는 제품이 있었습니다만, 개인버전이 $150입니다. 시험판을 써보고, 실제로 구매할까도 생각했습니다만, 시험판 라이센스를 구하는데 실패했습니다. 라이센스 담당자가 두번째 보낸 메일을 무시하더군요. 제가 앞으로 임베디드 소프트웨어 개발을 전문적으로 할 것도 아니고, 그냥 무료판 구해다 하는데 결정적 도움을 주었습니다.

결국 오래전에 떠났던 이클립스 (Eclipse)판으로 돌아왔습니다. 오래전 자바 개발할 때 쓰던 환경인데, 이렇게 임베디드용 C개발을 위해 돌아도다니, 참 모를 일입니다. 어쨌건 새로 설치해보니 Cocoa인터페이스로 재무장한 이클립스, 아주 더 멋져진 모습입니다.

Eclipse CDT환경을 설치하고, Zylin사의 Embedded CDT 플러그인을 추가로 설치합니다. 이 플러그인이 OpenOCD와 GDB프로토콜로 통신해서 이클립스 환경에서 디버깅을 할 수 있습니다. 



5. 연동 성공!

이런 구성으로 연결해서 간단한 예제를 컴파일하고, 얹어보고, 디버깅하는데 성공했습니다. 다른 구성 방법도 많이 있겠지만, 일단 OS X에서 개발 가능하다는데에 크게 만족스럽습니다.

이렇게 설정은 그럭저럭 해결한 거 같습니다. 이제 그럼, 얹을 소프트웨어를 개발해 봐야겠습니다. 



Posted by hatemogi 트랙백 0 : 댓글 14

댓글을 달아 주세요

  1. addr | edit/del | reply donny 2009.08.20 17:40

    오오오~~~ 매우 훌륭하삼~ 언제 또 이런 걸했나? 조용하다싶더니 뭔가 하고 있었구만!
    맨땅에 헤딩하면서도 저런걸 다 찾아서 연동에 성공하다니 역시 재주가 남다르단 말이지!
    뭔가 근사한거 한번 만들어봐~ ^^

    • addr | edit/del hatemogi 2009.08.21 21:19 신고

      와, 이거 진짜 맨땅에 헤딩 맞는거 같어. 어릴쩍 생각도 나고 재밌긴 한데, 결과물이 잘 나올지 걱정이 앞서는구만. 형말대로 무식하면 용감하다고, 아는게 없으니 겁없이 지르긴 했는데 말이지. ㅋㅋㅋ 가끔은 이런 용감무식함이 필요한듯.

  2. addr | edit/del | reply cybaek 2009.08.24 19:48

    이런 것에 대한 로망은 엄청 큰데 정말 뭘 어떻게 해야 어떤 결과물을 낼 수 있는지를 몰라서 손도 못대고 있다.
    보드는 4만원 밖에 안 하네?

    • addr | edit/del hatemogi 2009.08.24 20:23 신고

      생각보다는 저렴하더라구요. SRAM이나 FLASH메모리도 다 연결된 채로 준비돼 있구요... 로망실현 화이팅~!

  3. addr | edit/del | reply cybaek 2009.08.25 23:02

    검색에 검색을 하다 http://www.devicemart.co.kr/mart7/ 여기에서 한 시간 놀았네. -_-;;;

    • addr | edit/del hatemogi 2009.08.26 10:30 신고

      흐흐, 제가 거기서 사재기한 물건 비용이 기십만원에 이릅니다. 전시회 상금 못타면 눈물날듯.

  4. addr | edit/del | reply irmus 2009.10.29 21:47

    안녕하세요~ 검색하다 들렸습니다 ^^
    임베디드쪽은 워낙 OS에 발목잡히는 경우가 많아 아예 Windows가 아닌 경우는 포기하고 살고 있었는데, 이렇게 OS X에서 사용되는 모습을 보니 뭔가 느끼는 바가 많은것 같습니다.
    몇가지 업데이트된 정보가 있어 알려드립니다.
    컴파일러는 CodeSourcery에서 G++ lite 버전을 여러 OS를 위해 제공하고 있습니다. 아쉽게도 OS X용은 없지만 소스코드도 제공하니 컴파일 해서 사용하시는 것도 좋을듯 합니다. gcc 4.4 코어입니다.
    오늘(!) myCortex 개발환경을 업데이트해서 웹페이지 업데이트 했습니다. 새로 예제를 다운로드 받으시면 OpenOCD 0.2.0 기준으로 정리해 두었으니 참고하실 수 있습니다.
    그리고 eclipse에서 zylin의 CDT plug-in을 쓰셔도 되고 공식 CDT 플러그인이 있답니다.
    이상은 Stellaris-JTAG 개발환경 설정에서 사용하고 있는 조합이니 문제가 생겼을 때 참고하실 수 있을것 같습니다.
    사용하시다 궁금한점 있으시면 언제든지 질문 남겨주시고, 좋은 결과 얻으시길 바랍니다.

    • addr | edit/del hatemogi 2009.11.04 17:42 신고

      안녕하세요, 반갑습니다. 제작사에서 일하시는 분인가봐요. OpenOCD 0.2.0에서 연결했을때, 조금 의심스러운 부분이 있었는데, 올려주신 부분을 받아서 다시 확인해봐야겠네요. 감사합니다. 개인프로젝트인데 좀더 재밌게 진행이 돼서 이것저것 여쭤봐가며 해볼 수 있으면 더 좋겠네요.

  5. addr | edit/del | reply void_main 2011.01.31 19:00

    안녕하세요 글 잘 읽었습니다 ^^
    다름이 아니라, MAC 에서 yagarto 컴파일러 설치 하는 방법이 너무 안풀려서 이렇게 글을 남깁니다.
    어떤 블로그를 보면 MAC 용 설치파일 다운받아서 설치만 하면 된다고 하는데..

    다운 받아도 패키지는 있는데 설치를 해도 컴파일러가 설치도 안되고
    바이너리로 설치 할려고 해도 잘 안돼네요

    혹시 바이너리로 설치 하셨나요?

    • addr | edit/del hatemogi 2011.02.07 12:54 신고

      안녕하세요, 바이너리로 설치했습니다. 스노레퍼드에서는 인스톨러가 정상 작동하지 않아서, dmg마운트하고 해당 볼륨으로 들어가서 7zip으로 압축되어있는 파일 풀어서 /usr/local에 이동해 놓고 사용했습니다.

  6. addr | edit/del | reply tt 2011.06.09 12:36

    openocd 빌드 방식좀 알수 있을까요? git로 받고 bootstrap -> configure -> make 하던중 컴파일 오류가 나서요 ^^;;;

    • addr | edit/del hatemogi 2011.06.14 17:03 신고

      libusb(?) 가 미리 설치되어있어야할거에요~

    • addr | edit/del hatemogi 2011.06.14 17:41 신고

      방금 git으로 받아서 빌드해보니, tex관련 에러메시지가 보이네요. 시스템에 tex잘 맞춰놓으면 될것 같은데요... 음, 일단 문서들 제외하고는 잘 빌드되는거 같습니다. 아쉬운대로 Makefile에서 doc디렉토리 제외시키고 빌드하심 될거에요. 그리고 src디렉토리 보시면 실행파일 빌드되어있으실거 같아요.

    • addr | edit/del hatemogi 2011.08.20 18:15 신고

      엇, homebrew에 openocd가 추가되었네요. homebrew설치하시고, brew install openocd 하시면 한방에 설치됩니다. 만세!

WWDC에 성능 관련한 주제가 여러개 있는데, GCD(Grand Central Dispatch)와 OpenCL가 주요하게 소개되고 있다. MacOS X Leopard의 다음 버전인 Snow Leopard에 적극 활용되는 기술들인 듯. GCD의 경우 멀티코어CPU에서의 병렬처리를 돕는 기술인것 같고, OpenCL은 CPU와 GPU를 모두 활용할 수 있는 병렬 컴퓨팅 기술인것 같다. 

내가 쓰고 있는 MacBook Pro 15"만 하더라도, 듀얼코어 CPU한장에다가 GPU는 두장이 들어있다. 화면 디스플레이에는 전력소모가 적은 Integrated GPU만을 쓰고 있기때문에 나머지 한장은 완전히 놀고 있는 상황인거지. (Integrated GPU의 경우역시 거의 놀고있는걸테고 말이다)


OpenCL사이트의 소개문서에서 발췌한 그림이다. OpenCL용 C소스코드를 런타임에 원하는 타겟 프로세서용 코드로 컴파일해서 활용할 수 있다. 상황에 따라 CPU가 될 수도 있고, 아마도 일반적으로는 GPU를 대상으로 할테다. 컴파일된 바이너리는 특정 GPU에 최적화된 코드가 실행될 테고, CPU와는 별도로 병렬 실행되는 구조이다. GPU가 잘하는 일들을 하드웨어 수준에서 빠르게 병렬처리하는 코드를 만들어 활용할 수 있다는 아이디어겠다. (예전의 MMX나 SSE등의 SIMD기술들을 연상시킨다)

OpenCL소스코드는 C소스 비슷하게 생겼는데, 특화된 데이터타입이나 연산자들 함수들이 들어있다. 이 소스를 메인프로그램의 C코드에서 읽어들여, CL함수에 컴파일을 요청하고, 결과로 나온 커널을 실행하는 구조. 

(참고로, 아이폰 3G S에서 지원하는 OpenGL ES 2.0의 Programmable Shader의 경우에도 같은 형태의 컴파일/실행구조다)

한참 하이레벨인 루비쪽에서 놀다가, 이런 C코드 수준으로 내려와서 하드웨어 종속적인 사고를 보고 있으니 참 흥미롭기도 하고, 어떻게 보면 참 구차하다 싶기도 하지만, 분명 이런 성능 관련한 주제가 크게 관심있었던 매력적인 분야임은 부정할 수 없다. 

아마도 내가 직접 병렬처리를 활용하게 된다면 이와는 전혀 상관없이 Erlang을 쓰게 되겠지만, OpenCL같은 하드웨어와 밀접한 환경과 아이디어 자체는 흥미롭게 공부해볼 수도 있겠다. 혹시 또 알아? 내가 직접 쓰게되는 일이 생길지, 그 누구도 모르는 거지.

TAG wwdc
Posted by hatemogi 트랙백 0 : 댓글 0

댓글을 달아 주세요

학창시절의 꿈 하나

2009.06.11 09:10 from programming
Creating iPhone Apps that Communicate with Accessories

이번 WWDC의 전체적 관심주제는 당연히 아이폰 개발. 그중에서도 OpenGL ES에 관심이 많았다. 오늘 OpenGL에 관련한 세션이 많았는데, Intro수준의 세션에는 들어가지 않았다. 줄이 너무 길기도 했고, 나중에 동영상으로 봐도 다 따라서 이해할 수 있을 것 같다는 판단 때문이었지. 

같은 시간에 다른 홀하는 세션 중에 위의 제목의 세션이 있었는데, 아이폰과 외부장치와의 통신을 담당하는 API 프레임웍을 소개하고 데모를 보여주는 세션이었다. 

아이폰이 외부 하드웨어와 통신 할 수 있는 방법은 크게 3가지, 블루투스, UART, USB. (WiFi는 논외로 하겠다). 이중에 UART/USB에 관심이 많이 갔지. 그중에도 UART를 이용한 예제는 오래전 학창시절의 꿈을 상기시켜주었다. 


학창시절의 꿈 하나

학창시절에 컴퓨터로 외부 하드웨어를 제어하는 데에 관심이 있었다. 당시 만들었던것이 장난감 탱크를 컴퓨터 키보드로 제어하는 프로그램과 인터페이스였다. 하드웨어 인터페이스 관련 지식은 전혀 없었기 때문에, 당시 통신망에 떠돌던 패러럴 포트 연결한 LED제어 인터페이스 회로도를 구해다가 병렬로 연결해서 쿵짝쿵짝 만들었던 기억이 있다. 

기계적 릴레이 스위칭 회로를 병렬로 이어붙어 별도 공급하는 직류 전원의 +/-를 교체하기 위해 이래 저래 회로를 구성하느라 밤을 샜던 기억도 있다. (당시에 donny형도 함께였고). 프라모델 탱크를 전후좌우로 움직일 수 있는 프로그램을 만들어 PC의 패러럴포트의 4개핀을 이어 4비트로 제어했었고, 추후에 조금 확장해서, RC자동차를 제어하는 모델로 발전시켰었지. 당시 학과 동아리 전시회에도 출품했었는데, 아주 인기 만점이었다. :)

추후에 더 확장하고 싶었던 내용은, PC수준에서 RC자동차의 예상 움직임을 시뮬레이션해서, 원하는 신호를 적절한 타이밍에 내보내서, 실제 움직임이 그와 같은지 확인하는 프로그램이었다. 자동차의 움직임 시뮬레이션이라는 분야가 "Vehicle Dynamics"라는 동역학 분야의 하나라는 사실을 알기위해서만도 학교 도서관을 한참 돌아다녔던 기억이 난다. (찾고 나서 그 방대한 자료와 수식들에 나가떨어졌지만 말이다) 

대학 생활이라는 것이 공부말고 재밌는 것들이 너무도 많았던 나머지, 얼마 지나지 않아 흐지부지되고 노느라 바빴던 것 같은데, 그 먼 기억속의 꿈이 오늘에야 다시 회상되다니, 거 참 신기하다. 

다시 해볼 수 있을까

오늘의 세션도 소프트웨어 개발자 측면의 이야기만 있어서, 어떻게 UART통신을 처리할 수 있는 하드웨어 인터페이스를 만들 수 있을 지는 깜깜하지만, 그래도 시간좀 들이다 보면 만들어 볼 수도 있지 않을까 싶다. 

꿈이라는게 다른 사람들에게도 의미가 있어야한다는 (내지는 경제적 가치로 이어져야한다는) 누구도 정의하지 않은 압박으로 인해 시들어져버린 나만의 소중한 꿈들이 되살아나며, 작은 생기가 감도는 기분이다. 

또다시 어느새 시들해질지 모르지만 말이다. 
TAG wwdc
Posted by hatemogi 트랙백 0 : 댓글 2

댓글을 달아 주세요

  1. addr | edit/del | reply donny 2009.06.11 19:47

    기왕이면 블루투쓰어떨까? UART보다야 좀 어렵긴하겠지만 뽀다구 날꺼 같지않아? ㅎㅎ
    닌텐도 위모트랑 연결하면 뭔가 재미있는 조합이 나올수도...
    탱크만들던게 아직 생생히 기억남 ^^
    결정적인 실수가 전시회장(단대부고)에서 시연을 앞두고 모기군이 110V 어댑터를 220V에 꼽았다는...
    근데 왜 배터리로 안하고 어댑터를 연결했었는진 잘 모르겠군. 아무튼 헐레벌떡 전파사에서 새로 사다가 구동하는데 성공했었음.
    전시회 하루전날 모터 +/-연결이 엉터리라 거의 포기할 뻔 했는데 모기군이 한 5분 남짓만에 놀라운 집중력을 발휘하여 회로를 수정해냈은. 고등학생때도 논리적 사고에 아주 소질이 있었지 ^^

    • addr | edit/del hatemogi 2009.06.12 02:24 신고

      음, 나한테는 UART 디바이스도 어려울거 같은데, 블루투스는 어떠려나? 하드웨어 만들려면 뭐부터해야할지도 모르는 사람에게 말야. ㅋㅋㅋ 이젠 그때처럼 손으로 납땜하고 그럴수는 없을거 아냐. 그마저도 형이 다 깔끔하고 반짝이게 납땜해줬었는데...

      내가 아답터를 태워먹었군. 형의 기억력은 존경스러움을 넘어 무섭다니깐. 어댑터를 썼던 이유는, 해당 전원이 탱크 모터에 직접 전원을 공급해야했는데, 탱크가 캐터필터(?)에 대한 부담으로 인해 전력 소모가 어마어마했기때문이었던거 같아. 밧데리로 했다면 전시기간 내에 밧데리 꽤 많이 써야했을 듯. 아마 아답터 못구했으면, 랜턴같은데 들어가는 밧데리로 대체할 수 있었을거 같아.

      그 전류 방향 전환 로직은 지금 생각해도 신기해. 어떻게 해결할 수 있었을까... 집에 어디 구성도가 남았을지도 모르겠다.

      재밌었어. 흠... 재밌었어.

극성스런 호들갑

2009.06.09 12:59 from programming
WWDC 키노트

Apple Worldwide Developers Conference의 첫째날. 첫날 아침의 키노트를 듣겠다고 아침 일찍부터 숙소를 나섰다. 일부 극성스러운 사람들은 전날 저녁부터 가서 밤새 기다리는 열성을 보였지만, 난 그보다 잠을 더 사랑하기에 그럴 수는 없었다. 그래도 나름 실제 진행하는 컨퍼런스 룸에서 (참가자가 너무 많아서, 일찍 간 사람이 아니면 다른 홀에서 생중계로 보아야했다) 보고자, 두시간이나 일찍 가서 줄을 섰지만, 결국 생중계로 보게되고 말았다. 생중계도 꽤 볼만하더군, 장비들이 너무 좋아서, 화면도 아주 깨끗하고, 발표자 모습도 클로즈 업해주어서 오히려 보기 좋다고 생각했다. 생중계 홀은 자리 경쟁도 치열하지 않아서 앞자리에서 볼 수 있었고 말이다. 기대했던, 한국 아이폰 출시소식은 전혀 언급되지 않았다. 이제, 한국의 아이폰 출시 관련한 그 어떤 루머도 믿지 않겠다. 춥고 졸린 아침에 밥도 굶고 2시간이나 기다리는 호들갑도 떨지 않겠다.

개발자들, 내지는 geek들

얼마전에 조나단이랑 얘기하다가, 이런 얘기를 한적이 있다. "난 컴퓨터를 다루는 데에는 아주 능숙하지만, 사람들과 어울리는 데는 아주 미숙하다"고. 아마도 이런 특성이 개발자들의 공통된 특성이자 문제점이 아닐까 싶어. 고작 세 번의 해외 컨퍼런스에 참석하지만, 미국의 개발자들도 비슷한 특성이 있어보인다. 

컴퓨터를 상대로 일을 하지만, 결국은 사람을 위한 일을 하는 것 임을 잊지 말아야 할텐데 말이다. 이상하다, 예전 같으면 열광했을 법한 기술들에 대한 얘기들을 들어도 별 감흥이 없다. '음, 그래 좋은거네, 잘했네' 정도? 

그 극성스런 호들갑들이 다 자잘한 행복거리이자 열광의 대상이었던것 같은데 말이다. 그래도 아직 몇가지 내용들은 내 가슴을 뛰게 하더군. 뼈속 깊이 개발자임에는 아직 변함 없겠지. 

이제 무엇이 나의 가슴을 뛰게하는가.


TAG wwdc
Posted by hatemogi 트랙백 0 : 댓글 10

댓글을 달아 주세요

  1. addr | edit/del | reply BT_비티 2009.06.09 14:07 신고

    사람들과 어울리는데 전~혀 미숙해 보이지 않더만요... 특히 일본 사람과는 더 사근해 보이구요... 흠...

    • addr | edit/del hatemogi 2009.06.10 03:19 신고

      으흐흐. 외국에서 한국사람 만나면 제일 반갑고, 그다음은 일본사람, 그다음은 스웨덴 사람이더라구요. 형처럼 인사도 잘하고, 허그도 잘하고 해야 잘어울리는거죠. 그래도 여행중에 많이 좋아지고 있는듯.

  2. addr | edit/del | reply donny 2009.06.09 19:14

    오오~ 결국 WWDC에 갔군.
    잡스형의 키노트를 볼 수 없었음이 좀 아쉽네.
    아이폰3GS는 북미제외 76개국에 출시한다던데 그럼에도 한국은 빠졌다는... ㅋ

    나이들면서 모르는 기술이 생겨도 그리 조바심이 나지않는다는거 꼭 나쁘지많은 안을 수도 ^^

    • addr | edit/del hatemogi 2009.06.10 03:21 신고

      여기 온거 자체가 좀 극성이지. 잡스형, 평생에 한번은 봐야할텐데, 이번 기회가 아님이 아쉽군. 이제 한국 출시에 대해서는 기대없이 세계시장을 무대로 장난감 하나 만들어야겠어.

      형도 얼릉 애플로 귀환해. ㅋㅋ 나에게 애플컴퓨터를 물려준건 형이었잖아? 벌써 한 25년 전 얘긴가?

  3. addr | edit/del | reply 은영 2009.06.10 16:06

    가끔 너의 글에 이해할 수 없는 문장들 중 하나가 사람들과 어울리는데 미숙하다라든가 조용하다라는 글들..-_-
    내가 보기엔 넌 무쟈게 잘 어울리거뎡...ㅡ.ㅡ;;; 오히려 내가 부족하지..흠흠...

    • addr | edit/del hatemogi 2009.06.11 04:45 신고

      으흐, 나 안그런거야? 자신감을 심어주는군... 좀 나아지고 있긴 한데, 그래도 마이 부족하자너. 최소한(!) 윤섭정도는 되어야지.

  4. addr | edit/del | reply donny 2009.06.11 19:41

    자식 내성적인 척 하기는 ㅋㅋ

    • addr | edit/del hatemogi 2009.06.12 02:25 신고

      하하하. 다들 부정하는군. 이쯤 되면 나의 착각이었던 걸로 결론나는 건가?

  5. addr | edit/del | reply 아현 2009.09.20 14:31

    ㅋ. 어려운 질문이네. 이제 무엇이 내 가슴을 뛰게 하는가..
    얼마전에 필리핀에 다이빙을 다녀왔어. 이콜라이징과 배멀미때문에 고생하는 나를 보며 강사가 왜 다이빙을 하냐고 하더군
    여러가지 대답을 해줬는데 강사는 이해를 못하더군.
    역시 나의 공감이 남에게는 이어지기 어려운가바.ㅋㅋㅋㅋㅋ 언제나 나를 시험해 보는 나의 마음을 남에게 전하기 힘들더라고...

    • addr | edit/del hatemogi 2009.11.04 17:37 신고

      점점 각자의 길을 소신껏 즐겁게 가면 되는거 같다는 생각이 강해져. 운이 좋다면 동반자가 있을 것이고, 그렇지 않더라도 외로워할 수는 없는거라고 생각중. 오히려 자기만의 길이기때문에 유일한 가치가 있는거 같기도 하고..