현재 위치

홈 ›› Forums ›› 이슈 ›› 토론, 토의

firmware 개발자 vs 애플리케이션 개발자

xmlParser의 이미지
글쓴이: xmlParser / 작성시간: 토, 2005/12/31 - 8:18오후

극단적으로 얘기해서 두 파트중에 어느 파트에 무게 중심이 좀 더 있을까요.
요즘은 하드웨어를 만드는 회사에서 디바이스 드라이버까지 대부분 제공이 되고 있기 때문에 개인적인 생각이지만, 펌웨어 개발자는 단지 그것을 포팅하는 정도의 지식만을 요구하지 않나 하는 생각이 듭니다.
잘못된 생각이라면 충고 부탁드리구요, 여러분들의 생각을 듣고 싶습니다.

Forums: 
토론, 토의
saxboy의 이미지

글쓴이: saxboy / 작성시간: 일, 2006/01/01 - 1:35오전

어차피 하드웨어 벤더에서 제공하는 드라이버나 커널, 또는 미들웨어도 다들 비슷비슷한 개발자들이 만든 것입니다. 제품에 적용하다보면 문제는 항상 생기게 마련이지요. MS 나 인텔에서 제공되는 코드라도 당연히 완벽하지 않습니다. 게다가 벤더는 수많은 업체를 상대로 하는 경우도 많고, 그렇지 않다고 하더라도 능동적으로 대응해주지는 않습니다. 결국 작동에 대한 책임은 대부분 담당자에게 있게 마련이고, 담당자는 현실적으로 직접 개발을 하지는 않는다고 하더라도 벤더의 서포트를 요청하기 위하여 직접 코드를 테스트하고 문제를 찾아내야 하는 경우가 자주 생깁니다. 그리고 이렇게 하기 위해서는 코드의 작동 방식을 대부분 알고 있어야 합니다.
그리고 만일 제품 사양에 있는 기능이 하드웨어 벤더에서 제공해준 것만으로는 구현이 되지 않는다면 어떻게 해야 할까요. 8)

물론 어플리케이션이 중요한 것은 말할 나위도 없지요. 실제로 칩이나 보드의 구성에 대해서 전혀 알지 못한다고 하더라도 임베디드시스템을 개발하는 팀의 일원으로 일하는 것은 충분히 가능합니다. 하지만 하드웨어에의 의존성이 높은 어플리케이션이라면 드라이버나 하드웨어의 특성을 알지 못한다면 제 성능을 내지 못하는 경우가 많습니다.

고도리의 이미지

글쓴이: 고도리 / 작성시간: 일, 2006/01/01 - 4:04오전

둘 다 비중은 비슷할 거라고 생각합니다만, 하는 일의 성격에 따라 틀려지겟지요.

1. 제공되는 fw(혹은 driver)코드가 잘 동작할 경우
당연히 application쪽으로 비중이 가겠지만, embedded system에서는
안심을 못하므로, fw쪽도 스트레스 받기는 비슷하고, 당연히 필요하고요.

2. 잘 동작하지 않을 경우
fw나 드라이버 개발자는 반 죽는거고요. application도 나름대로 반 죽습니다.
일단 드라이버가 되어야 프로그램을 작성할 수 있을테니깐요.

관점에 따라 많이 틀려지긴 하는데, 요즘은 fw나 driver 개발자가 그렇게
많지 않아 보입니다. 점점 줄어들어간다고 해야하나, 아니면 아무도 안한다고
해야하나....돈이 조금 되는 기술이기때문에 전파를 안하나...^^

제가 아는 pmp업체의 경우, fw나 드라이버 파트는 많은 인원이 아니고
app쪽은 많은 인원이 있습니다. 하지만, 일의 주력은 fw나 드라이버쪽이
되겠지요. app인원은 그나마 구할수 있으니깐요.(참고로 드라이버 하시는 분들이 다 app도 잘하시는 분입니다.)

두쪽 파트다 중요하다고 생각하지만, 요즘 생각에는 인력을 얼마나 구할 수
있느냐에 더 비중을 둡니다. fw나 driver엔지니어 잘하는 사람 구하려면
정말 하늘의 별따기 입니다.

ps> 대기업에서는 아예 싹쓸이를 해가더군요...--;

서명.....음, 서명이라...

아싸!!! Three Go!

saxboy의 이미지

글쓴이: saxboy / 작성시간: 일, 2006/01/01 - 2:15오후

아... 그러고보면 제공되는 코드가 "샘플"인 경우도 자주 있지요. 흐흐...

hook의 이미지

글쓴이: hook / 작성시간: 월, 2006/01/02 - 9:37오전

제일 쌈많이 나는 말인데 쩝..

자기하는일이 비중이크다 T.T

blkstorm의 이미지

글쓴이: blkstorm / 작성시간: 월, 2006/01/02 - 10:16오전

embedded APP하다가 디바이스 드라이버로 업무를 바꾼 제 경험으로는...

어떤 기기냐, 어떤 식으로 개발되느냐에 따라서 많이 다른 것같습니다.

예를 들어, 자체적으로 개발한 SoC나 chip을 갖고 있는 회사라면 디바이스 드라이버 엔지니어가 중요합니다. 제 경우(SoC)에는 옆팀에서 준 디바이스 드라이버 코드 가져다가 아무리 봐도 비효율적인 것같아 보였습니다.그래서 제 맘대로 뚝딱뚝딱 고치니깐 동일한 기능에 동일한 레지스터 오퍼레이션 사이클을 돌리는데 사이클 효율이 10%정도 향상되더군요. 솔직히 저런 식으로 디바이스 드라이버들을 최적화하면 성능을 높이는데 기여를 많이 하게 됩니다.

그러나, 만약 다른 vendor로부터 chip을 공급받는다면 그때부터는 APP에 업무를 집중하면 됩니다. DDI/API문서들을 잘 정리해 놓고, 해당 chip에서 문제가 발생할 경우에 bug report를 제대로 해주고, vendor에서 제때제때 답만 해준다면 개발자 입장에서는 app에 전념하면 됩니다.

그렇지만, 이것 또한 절대적인 기준이라고 볼 수 없는 것이... 아무리 디바이스 드라이버나 app가 최적화 되어있어도, 한 태스크에서 비 효율적으로 clock을 많이 잡아먹으면 최적화의 의미는 퇴색됩니다. 어차피 커널이건, 디바이스 드라이버건, app건 CPU입장에서는 clock이라는 자원을 공유하는 모두 application이기 때문에, 어느것이 더 중요하다고 결정하는 것은... 글쎄요, 소모적인 논쟁이 아닐런지...

결국 닭이 먼져냐 달걀이 먼져냐와 동일한 논쟁이라고 생각합니다.

dipole의 이미지

글쓴이: dipole / 작성시간: 월, 2006/01/02 - 11:12오후

이것 저것 닥치는대로 하는 상황인 제 경험에서 보면
약한쪽이 비중이 높습니다만 웬만하면 어플이 높은 경우가 태반이구요,
같다면 당연히 어플리케이션이 비중이 높죠.

드라이버가 쪽이 약하다면 디버깅은 한도 끝도 없게 됩니다.
하지만 드라이버는 보통 하드웨어적인 안정성이 확보되면 웬만해서는 업데이트
할일이 거의 없게 됩니다. 내적으로는 드라이버의 안정이 굉장히 중요하고
잘짠 드라이버는 웬만큼 바뀐 어플구조에서도 대처가 가능하고 거의 바뀌지 않게 되지요

하지만 어플은 말그대로 어플 즉 사용자의 요구나 사양에 따라 대처를 해야
하므로 상당한 고수정도나 되어야 웬만한 사양에 대처한 코드를 짜게 되죠.
일이 끝도 없고, 가장 마지막까지 작업해야 하는 부분이라 외형적으로는 중요하게 보입니다만 제가 느끼는 어플작업은 "노가다" 그 자체라고 봅니다. ㅡ,ㅡ

너는 누구냐?

gurugio의 이미지

글쓴이: gurugio / 작성시간: 화, 2006/01/03 - 2:46오후

어떤게 어플리케이션인지 모르겠지만
제가 있는 연구실에서는 지능형 로봇 원격 제어나
비전 시스템에 대해서 연구하는데요
우리가 원하는 어플리케이션 자체가 임베디드 보드에서 돌아가야하고
또 일반적으로 파는 보드가 아니라 우리가 쓰는 FPGA나
비디오 칩들을 달아야 하기 때문에
보드도 만들고 firmware도 짜고 드라이버도 짜고
필요하면 OS도 얹고
그래서 최종적으로 어플리케이션을 만듭니다.

제 생각에는 PC 기반이 아니라면
어플과 로우레벨 이런 구분이 무의미할것 같구요

PC 기반이라도 완전히 납땜만 하고 넘겨주는 일이 아니라면
어떤 라이브러리를 쓰는지 어떤 언어를 쓰는지가 다를 뿐
다를게 없는 작업인것 같습니다.
제가 어플리케이션 개념을 몰라서 그런것 같기도 하네요..

eou4의 이미지

글쓴이: eou4 / 작성시간: 수, 2006/01/04 - 12:51오전

쉽게말해서 펌웨어 개발자는 기계와 친해야하고..

어플리케이션 개발자는 사람과 친해야 할 듯 합니다.

그리고.. 주제와 관련해서는.. 펌웨어 개발자는 드라이버 개발도 할 수 있어야 발전이 있을 것 같습니다.

ㅎㅁㅎ

둘러보기