많은 취준생분들이 궁금해 하는 질문을 소개합니다.
* 임베디드 개발자는 실제로 어떻게 개발을 할까?
이번 포스팅에서는 이 주제에 대해 설명하겠습니다.
임베디드 개발에서 생각보다 다양한 개발자들이 포진돼 있어 임베디드 개발을 정의내리긴 힘듭니다.
하지만 대표적으로 예시를 들어보면 다음과 같습니다.
* 특정 제품을 개발
* 제품이 출시된 후 유지 보수
* 특정 솔류선을 제공
이 밖에도 다양한 분야에서 임베디드 개발이 이루어지는데요. 이 중에 가장 많은 개발자가 포진돼 있을 것이라 보는 '제품 개발 관점'의 임베디드 개발에 대해 설명을 하겠습니다.
보통 특정 제품을 개발할 때는 임베디드 개발은 다음 단계로 진행됩니다.
* 제품의 컨셉과 하드웨어 부품을 산정(기획)
* 보드 브링업
* SW의 안정성을 확보
* 인증 테스트를 통과
* 고객사나 앤드 유저에게 납품(출시)
* 유지 보수
먼저 제품의 컨셉과 하드웨어 부품을 산정하는 단계에 대해 알아보겠습니다.
제품의 컨셉과 하드웨어 부품을 산정(기획)
대다수의 임베디드 개발자들은 프로젝트의 첫 단계는 보드 브링업이라 예상합니다.
하지만 프로젝트의 첫 단계는 '제품의 컨셉과 하드웨어 부품을 산정'하는 기획 단계입니다.
프로젝트를 시작하는 단계에서 가장 먼저 제품의 컨셉과 가격을 정합니다. 물론 경쟁 업체의 가격과 스팩도 고려해야 되죠. 이 과정에서 자연스럽게 제품을 구성하는 부품의 스팩과 가격을 선정합니다. 프로젝트 리더나 매니저들은 임베디드 개발자에게 다음과 같은 내용에 대해 점검해달라고 요청합니다.
* 해당 부품을 선정해 개발할 때 리스크가 없는지
* 해당 부품으로 일정 내에 정한 스팩을 맞출 수 있는지
또한 어떤 SoC(System-on-chip)를 선정할 지, 어떤 메모리 부품을 탑재할 지 문의를 하기도 합니다.
한 가지 예를 들까요? 기존에 최대 1.2 GHZ의 CPU 클럭을 지원하는 SoC를 선정했는데 이번에는 1.8 GHz CPU 클락을 만족해야 합니다. 되도록 기존에 개발했던 SoC를 활용하고 싶은데 CPU 클럭이 낮습니다. 이 때 새로운 SoC를 선정해야 하는 상황이죠.
이번에는 다른 예를 들어 볼까요? 카메라 디바이스인 경우 카메라의 화소와 실행 시간을 결정하죠.
여기서 임베디드 개발자에게 선정된 부품으로 Resolution과 화소를 만족하는지 확인을 해야 합니다.
여기서 개발자는 부품에 대해 충분히 리뷰하지 않고 지정한 부품이 문제없이 동작할 것이라고 대답하면 안됩니다.
이 밖에 부품 업체에 대해 다음과 같이 내용을 체크해야 합니다.
* 선정한 부품이 제품의 스팩을 만족시키는지
* 부품 회사에서 기본으로 동작하는 드라이버 코드를 배포하는지
* 선정하려는 부품 업체에서 기술 지원을 제대로 하는지
이 과정에서 자연스럽게 부품 업체에서 제공하는 데이터 시트를 리뷰하게 됩니다. 이와 같은 하드웨어 부품의 스팩을 점검하는 일은 매우 중요합니다. 그 이유는;
* 초반에 부품의 스팩은 면밀히 검토해야 하는데 스팩이나 부품 업체의 특징에 대해
제대로 파악하지 못하면 실제 개발을 진행할 때 고생하는 경우가 있거든요.
한 가지 예를 들어 볼까요?
* A란 메모리를 탑재했는데 알고 보니 지정한 SoC에서 A란 메모리를 충분히 검증하지 않아 비트 플립이 발생할 수 있다.
이 밖에 수 많은 예시를 들 수 있는데요. 개발 초기 단계에 부품의 스팩과 부품 업체의 전반적인 지원에 대해 파악하지 못하면 개발 도중 피를 보게 될 수 있어요. 그러니 개발 초기에서 부품을 선정할 때 신경을 많이 써야 해요.
브링업
임베디드 개발를 하면 가장 많이 듣는 용어가 브링업(Bring-up)이지 않을까요?
대부분 임베디드 개발자들은 브링업 업무를 진행하며 이 과정에서 고생을 많이 하고 고생에 비례해서 많은 걸 배우기도 하죠.
그럼 브링업이란 무엇일까요?
브링업이란 일반적으로 부팅이 안되는 상태의 보드를 받아 기본 동작을 하는 수준까지 드라이버를 살리는 작업을 뜻합니다. 브링업을 조금 더 포장해 설명을 하면 '기계에 생명을 불어 넣는다'라고 말할 수 있습니다.
자, 여기서 의문이 생깁니다.
* 과연 테크니컬한 관점으로 브링업이란 무엇인가?
이제부터 개발자 관점에서 브링업에 대해 이야기를 하겠습니다. 우선 브링업을 하는 디바이스가 ARM 아키텍처 기반에서 동작한다고 가정하겠습니다.
보드를 브링업하는 가장 첫 단계는 우선 보드에 다운 로드를 할 소스를 빌드해야 해요. '부트로더 + 커널 + 시스템' 이미지가 생성되게 빌드해 놓고 다운로드를 시작해야 하는 거죠.
보드에 다운로드를 하는 방법은 SoC에서 제공하는 툴을 사용하거나 TRACE32로 할 수 있습니다.
그럼 다운로드를 마친 보드에 전원을 인가하면 가장 먼저 ARM 아키텍처에서 Reset 벡터 코드가 실행이 됩니다.
해당 코드를 스타트업 코드라고 부르는데 이 때 부트로더를 초기화하는 코드가 동작합니다.
위에서 코드라고 불렀는데 이 때 C언어가 아니라 어셈블리 코드가 동작합니다. 그래서 부트로더가 동작을 하고 부트로더가 커널 이미지를 로딩하고 커널 이미지가 유저 공간의 라이브러리를 로딩하는 과정을 거칩니다.
대부분 임베디드 개발에서 이 때 유와트(UART) 로그를 보면서 보드가 브링업되는 과정을 체크합니다. 유와트로 제대로 디버깅이 힘든 조건에서는 TRACE32와 같은 하드웨어 디버거를 사용해 시스템의 상태를 점검합니다.
이렇게 UART 로그를 보면서 부팅이 제대로 되는 지 체크를 하는데요.
브링업 과정에서 바로 부팅이 제대로 되는 경우도 있지만, 그 확률은 거의 10% 미만입니다.
대부분 부팅을 하는 과정에서 문제가 생겨 부팅을 못하는 상황을 겪는 게 대부분이거든요.
그 이유는;
* 크래시가 발생한다.
* 심각한 에러 메시지가 보이며 드라이버가 초기화되지 못한다.
주위 임베디드 개발자와 브링업에 대해 이야기를 하면 대부분 브링업을 싫어합니다. 가장 큰 이유는 브링업 업무를 할 때
야근을 할 가능성이 매우 높기 때문이에요.
최근 덧글