임베디드 시스템 소프트웨어 생산성 향상에 대한 고민
임베디드 시스템에서 생산성을 어떻게 올릴 수 있을까를 많이 고민해 왔습니다.
몇가지 생각해본것을 정리해보았는데 의견 부탁드립니다.
1. 스크립트 언어 Lua 를 이용한 개발
경량 스크립트 언어인 Lua 를 적용할 방법이 없을까 고민 해왔습니다. 공부를 시작한지 몇달만에 실전에 적용할 방안을 찾게되었습니다. 어디까지나 테스트 용도였지만 현재로써는 적용해봤다는 것에 만족하고 있습니다. 시작은 미약하나 끝은 창대하리라는 말 처럼 언젠가는 더 좋은 적용방법을 알 수 있을것이라고 믿습니다.
신제품을 개발하면서 매번 C 언어로 작성하여 컴파일 후 RS232 로 프로그램을 전송하여 디바이스 드라이버를 테스트 했는데 많이 번거로웠습니다. 해결책으로 Lua 를 ARM 용으로 크로스 컴파일 후 Lua 로 각종 디바이스 드라이버를 하였는데 매번 다른 테스트를 하면서 편집->컴파일->전송->실행 와 같은 복잡한 과정을 2단계로 단축할 수 있어 디버깅하는데 큰 도움이 되었습니다.
2. Flash 를 이용한 개발
임베디드 소프트웨어를 Flash를 이용해서 개발하는 것은 어떨까요? 이것이 가능하다는 것을 최근에 알게되었습니다. TV가 없는 저로써는 유뷰브를 즐겨보는 편인데 전원만 켜면 인기있는 비디오가 스트리밍되는 기기가 있었으면 좋겠다는 생각을 했었는데 우연히 임베디드 보드를 이용하여 유튜브 스트리밍 프로그램을 올리는 프로젝트를 알게되었습니다. 이 프로젝트의 핵심 아이디어는 ARM 기반 리눅스에서 Gnash 라는 오픈소스 플래시 재생프로그램을 이용하여 유튜브에서 제공하는 SWF (플래시 실행파일)을 실행하여 영상을 프레임버퍼로 보여주는 것이었습니다. 저는 여기서 플래시가 임베디드 소프트웨어 개발도구로써의 가능성을 엿보았습니다.
일단 성능에 대한 이야기는 접어두고, 이것의 장점을 설명드리겠습니다. 플래시를 이용하여 개발한다면 유저인터페이스 부분이 될것입니다. 플래시의 막강한 디자인툴과 액션스크립트를 이용하여 화려한 에니메이션과 유연한 메뉴구성이 가능할 뿐만 아니라 유지보수와 개발속도가 크게 향상될것으로 보입니다. 지금과 같이 개발자가 메뉴의 배치를 결정하는 형태가 아니라 배치는 디자이너에게 맡기고 개발자는 내부기능에 집중할 수 있습니다. GNU 플래시 플레이어 Gnash는 확장기능도 가지고 있어서 네이티브 컴파일러(C/C++)로 짜여진 공유라이브러리와의 통신도 지원합니다. 그래서 플래시로 작성된 버튼을 눌렀을 때 디바이스 드라이버에게 영상을 재생하라는 명령을 내리거나 저장하라는 명령을 내릴 수 있습니다.
이제 많은 분들이 우려하는 성능에 대해 이야기 해보겠습니다. Gnash 의 최저 사양은 ARM9 200Mhz / 램 32MB 이라고 합니다. 하지만 사용자들의 인내심을 테스트 하지 않기 위해서는 적어도 ARM9 3~400Mhz / 128MB 정도는 되어야 하는것 같습니다(웹사이트 참조). C로 작성하는것 보다 고사양의 CPU와 메모리가 필요하겠지만 개발기간 단축, 유지보수 비용 절감, 인건비 절감등을 고려한다면 상쇄가 될수도 있지 않을까요?
제가 너무 이상적이고 실현불가능한 생각만 하는지 모르겠습니다만 그냥 초보자의 생각이오니 많은 의견 부탁드립니다.
Gnash 개발 경험.......
안녕하세요. Gnash를 PXA270에 Porting 해본 경험이 있습니다. 2년 전이었던 같습니다.
지금은 Gnash가 얼마나 좋아졌는지는 모르겠네요.
Gnash를 쓰신다는 것은 리눅스를 생각하고 계신것이겠죠. ^^
Porting할 당시만 해도 Gnash 개발이 한참 진행 중이었습니다. 지금도 마찬가지겠죠. Gnash는 상업용이 아니다보니
개발자분도 틈틈히 작업하시는 것 같더군요. Gnash에 XMLSocket 지원여부를 확인하려고 컨택했는데, 그런 말씀을 하시더라구요.
아직 버그도 많고 문제도 많다고요. 그 당시에 Window만큼 화려한 Flash는 디스플레이가 안되는 경우도 있고, 일부만 디스플레이 되고(배경도 움직여야 하는데,
메인 이미지만 따로 논다던가 하는 상황) 그밖의 여러 기능들도 지원이 안되었습니다.(XMLSocket만 기억나네요. ^^;;;) 만약 생각이 있으시면, 충분히 리서치를 하신 후 진행하시는 것이 좋을 듯 합니다.
개발자분에게 물어보셔도 좋겠구요.
처음에는 Gnash도 진행하고, Adobe 사의 리눅스 Flash SDK도 컨택했지만 1000만원을 넘게 달라고 하더라고요.;;;;;
2년전이니 Gnash도 많이 좋아졌을 것이라고 생각하지만, 상업용으로는 충분한 고려가 필요할거라는 것이 제 생각입니다
그럼 좋은 하루 되세요.
플래시로 UI를
플래시로 UI를 구성하면 화려하고 멋진 UI에 UI와 코드의 분리 등등이 가능할 수도 있는데
현실은
느리다 => UI를 간략하게 만든다 => 비트맵보다 예쁘지도 않고 속도도 느리고 메모리도..
UI와 개발의 분리 => 플래시 개발자는 코드를 모르고 프로그래머는 플래시를 모른다 => 외주로 개발한다면 코드를 보여줄 수도 없다 => 책임은 빙글빙글 돌고..
얼마전에 WinCE도 영업하는 사람들이 신기술(?) 들고와서 보여줬는데 위의 내용에서 자유롭지는 못할 것 같습니다.
매우 적극적이고 긍정적인 사고를 가지고 계시네요
개발자들 스스로 생산성 향상을 대부분 생각하기가 쉽지 않고
실천하기는 더어려운 현실을 볼 때
chaeso 님은 매우 적극적이고 긍정적인 사고를 가지고 계시네요.
경력의 장단을 떠나 앞으로도 좋은 경험들 가지실 것 같습니다.
일단, target platform이 serial등 저속 통신만 지원하다면
Lua를 이용한 방법이 크게 도움이 되겠네요.
혹시 jtag, eithernet, rom emulator 등이 있다면 여기에
여러 종류의 sw, hw debugger를 연동하는 전통적인 방법들이
쉬울지도 모르겠네요, 특히, device driver라면.
어느정도 해상도가 있는 display장치를 쓴다면
아무래도 UI가 전체적인 개발기간에서 차지하는 비중이 크죠.
미려하고, 역동적인 GUI를 구현한다면 flash가
개발 과정 및 완성도에서도 좋은 답이 될수도 있을 겁니다.
개인적으로는 많은 application을 봐왔지만,
아직 이러 flash 구조의 ui는 실제품에서 접해본적은 없습니다.(핸펀이 있나?)
하지만, 이런 UI가
제품 가격 + 경쟁력 대비 개발비용 + 생산가격 상승 분을 상쇄 하거나
반드시 넘어서야 만 가능하것 같네요, 특히 생산 수량이 많은 제품일수록.
경쟁사 제품과 유사한 사양에서 flash ui는 분명히 제품의 경쟁력을 가져올겁니다.
임베디드 시스템 제품들을 보편적으로 생각해보면
일반 TV, 냉장고, 셋톱박스, 유사 가전, 각종 산업 제어 장치, 차량용 제어 장및 및 계기판 등으로
매우 큰 생산 수량에 치열한 가격구조를 가지고 있어
UI만을 위한 별도의 가격상승은 추가 하기는 어려울 수 있단 생각을 해봅니다.
오히려 회사는, 개발자의 능력 및 노동력을 더 믿어 (싸다는 점잖은 표현 -.-)
도구의 개선보다는 장인의 우수성 혹은 끈기로
해결해 주길 바라는 경우가 많을 지도 모르겠네요.
HW 사양변화를 최소화 하고 font, bitmap, menu, tree, layout등도 개발 및 재작업, 디자이너와의 분리등도
개발자의 능력으로 구현 가능한것들이 많이 있는 것 같습니다.
이미 수많은
이미 수많은 휴대전화/PMP에서 플래쉬 플레이어가 UI라이브러리로 돌아가고 있습니다.
제가 매크로미디어 코리아(지금은 어도비 코리아죠)하고 디지털 TV에 플래쉬 플레이어를 올리는
알파테스트를 했던게 2005년이었습니다. 그래픽 드라이버 연결하고 간단한 UI까지 올렸었습니다.
2005년(?)에 MX컨퍼런스라고 플래쉬 관련 컨퍼런스가 있었는데(매리어트 호텔), 그 당시 SS전자에서 나와서
플래쉬 UI를 발표했던 모 선임 연구원이 얼마전에 햅틱 UI개발의 주역으로 신문기사에 나왔더군요.
요즘은 ARM프로세서도 많이 빨라지고 플래쉬 플레이어도 플랫폼 별로 최적화가 많이 되었다고 들었습니다만,
제가 개발할 당시만 하더하도 각종 화면 효과를 위한 부동소수점 연산이 시스템 리소스를 많이 잡아먹어서
상당히 느렸던걸로 기억합니다.
(이 이야기는 kldp에서 정말 많이 우려먹네요 ㅎㅎ)
개발 초기에 개발 프로세스 셋업에서 헤매는 일은 많겠습니다만, (개인적인 의견으로는) 결국 대부분의
핸드헬드 기기나 가전기기에는 플래쉬 플레이어나 유사한 형태의 라이브러리가 사용될 것으로 생각합니다.
2002년쯤에 StrongARM
2002년쯤에 StrongARM 200MHz CPU 에 EIDE CD-ROM 을 붙여서
플래시 애니메이션으로 만든 애기들용 전자동화책을 구동하는 프로젝트에서 뛴 적이 있습니다.
저는 커널 쪽을 맡아서 플래시 플레이어에 대한 작업을 전혀 안 했었습니다만,
PC 에서 보던 유명 플래시 애니메이션들을 가져다 리버스엔지니어링 수준으로 작업하는 것 같았습니다.
아무튼 조작과 감상엔 별 무리없었고,
할 짓이 하도 없어서 부트로더에 CD-ROM 부팅을 구겨넣었을 정도로 심심하고 별 특이사항 없던 프로젝트였습니다.
(8bit I/O 가 없는 CPU 인데, PCMCIA용 메모리 영역을 이용한 꼼수로 I/O를 했던 기억이 나는군요)
이때 이후로 플래시를 (근거없이) 만만하게 보는 관점이 생겼고,
면접에서... 플래시 플레이어를 엄청 어렵고 대단한 것으로 주장하던 친구에게 좋지않은 점수를 줘버렸습니다.
뭐, 그때랑 지금이랑은 많이 틀리겠죠.
애니메이션과 UI 의 차이도 클테고.
OTL
...
2002년이면, Flash가 ActionScript 1.0 있던 초기 버전이군요. See Also http://en.wikipedia.org/wiki/ActionScript#Timeline_by_ActionScript_version
당시에는 획기적이지만 지금의 Flash입장에서 보면 많이 단순한 기능만 지원하던 플레이어였지요.
Adobe가 인수한후 3.0에 이르러 아예 코드를 새로 작성하고 Flash 9,10에는 ActionScript 2,3 용 2개의 VM이 담겨 있습니다. AVM1 (for AS1,2),AVM2(for AS3)입니다.
친구분께서는 미래를(?) 바라보고 그러신것 일수도 있겠다는 생각이 듭니다. :)
과거 Macromedia가 미친척(?)하고 Flash를 Open Source화 할뻔 한적이 있었습니다. 한정 유저들에게 소스가 공급됬고 이내 중단되었었지요.
그때 Java처럼 Spec주도, 구현은 여러업체 형식으로 가면 더 재미있는 일들이 많이 벌어졌을 것 같아요.
한 2년전 글인 줄 알았는데...
어제 나온 따끈한 글이군요. ㅇㅅㅇ
충분히 가능합니다.
더욱이 시스템에 '스크립트 언어' 엔진을 내장하는 것은 부득이 하게 아키텍쳐를 변환해야 하거나, 커널을 바꾸더라도 기존의 스크립트 기반 소프트웨어를 별도로 고치지 않고 사용할 수 있는 장점이 있습니다. 다만 '스크립트 언어'는 텍스트 에디터로도 소스코드를 볼 수 있다는 '장점'아닌 장점때문에 업체들에게 외면받고 있습니다. 따라서 오픈 플랫폼의 임베디드 장치를 설계하여 양산하고, 그 위에 자유소프트웨어를 올리는 프로젝트들이 다수 진행되고 있습니다.
개인적으로는 조금 돈이 비싸더라도, 오픈 플랫폼 기반 하드웨어 장치들이 널리 판매되고 사용되었으면 하는 바램입니다.
====
( - -)a 이제는 백수다.