libabov

ABOV 마이크로컨트롤러 개발도구

libabov 란

어보브 마이크로컨트롤러 개발을 위한 개발 환경을 제공한다. 저수준 하드웨어 드라이버와 라이브러리, 그리고 주변장치 예제를 포함한다.

어보브뿐만 아니라 다른 벤더사의 칩도 지원할 수 있는 확장성 있는 구조를 갖고 있다.

개발 동기

중간 규모의 프로젝트를 긴 호흡으로 가져가고 싶다는 욕구가 컸다.

스타트업에서 하드웨어 제품을 개발하면서 나의 개발 성향을 보다 명확하게 파악하게 됐다. 매일 대시보드를 보며 모니터링하는 기기 수가 늘어날 때마다 내 마음도 설레긴 했지만, 개발할 땐 응용 코드보다 저수준 코드가 더 눈에 들어왔다. 시장 반응을 살피기 위한 빠른 개발보다는 지속적으로 관리하고 개선해야 하는 인프라 쪽 개발이 내게 더 적합해 보였다.

최근 반도체 대란에 대안을 찾아보다 국내 업체인 어보브에 관심을 갖게 됐다. 소프트웨어 개발 지원이 아직 풍부하지 않아 내가 기여할 수 있는 부분이 있다 싶었고, 시장 점유율도(찾아보기 힘들정도로) 높지 않아서 오히려 성장 가능성이 높다고 판단했다. SDK 지원은 시장 점유율을 높이는데 제 역할을 할 것이고, 소프트웨어 지원에 따른 점유율 변화 추이를 살펴보는 재미도 있을 것 같았다.

그리고 공통된 개발 환경을 제공해 어보브뿐만 아니라 여러 마이크로컨트롤러를 쉽고 빠르게 개발할 수 있다는 것이 무엇보다 유력한 가치로 생각되었다.

로드맵

다섯단계로 각 개발 내용을 분류했다. 3단계 장치 드라이버까지가 SDK 개발이고, 그 다음 단계인 개발 플랫폼 구축은 SDK를 비롯한 주변 도구들을 사용자 중심으로 재배치하고 통합하는 과정이다. 마지막 단계는 마이크로컨트롤러 개발에 국한하지 않고 활용가능한 자원과 기술을 응용해 새로운 사업방향을 만들어 보는 것이다. 부분들을 종합하면 때때로 미처 의식하지 못한 통찰을 얻게 되기도 한다니까.

추상화 레벨에 따라 libabov 는 다음 세가지 계층으로 나뉜다:

layer

Low level APIs

첫번째 단계는 주변장치 레지스터를 직접 제어하는 API를 구현한다. 디바이스별 주변장치 레지스터를 등록하고, 메모리 맵에 따른 링커 스크립트를 작성한다. CMSIS(ARM의 경우)와 컴파일러 전처리기 이외의 의존성을 갖지 않는다.

추상화 수준은 낮지만, 디바이스 내부구조와 소프트웨어 빌드 프로세스에 대한 이해가 필요하다. 지원 디바이스가 늘어날수록 공통 코드를 분리하는 노력도 필요하다.

devices/ 하위 디렉토리에 계층화된 구조로 디바이스 종속적인 코드를 분리한다.

하드웨어 추상화 계층

하드웨어 추상화 계층은 실제 하드웨어 세부사항과 무관하게 기능별로 추상화된 하나의 공통 인터페이스를 정의한다. 상위 수준(사용자 응용 프로그램)과 하위 수준(low-level API)를 연결하는 역할을 하며, 동일한 코드를 여러 디바이스에 이식가능하게 한다. 이 추상화 계층은 확장성과 유지보수 측면에서 설계의 핵심이다.

기존 마이크로컨트롤러 개발은 벤더사별로 또는 디바이스별로 다른 개발환경과 SDK를 사용해야 한다. 예컨대, 노르딕은 nRF5 SDK, Espressif 은 esp-idf, ST 는 STM32 SDK, Cypress 는 WICED, 실리콘랩스는 Gecko 와 같은 서로 다른 독자적인 SDK 를 제공하고 있다.

호기롭게 이 프로젝트가 마이크로컨트롤러 개발에 de facto가 되는 꿈을 꿔볼 수도 있겠다. 새로운 개발환경에 대한 학습과 검증에 따른 개발비용을 제거하고 공통의 API로 호환성과 신뢰성을 높일 수 있다.

프로젝트가 성공적으로 진행되어 여러 벤더의 다양한 마이크로컨트롤러를 지원하게 될 경우, 호환성을 제공하고 유지하기 위해 많은 노가다성 변경사항이 이 계층에서 생길 것이다. 안정화된 버전이 나오기까지 제법 시일이 걸릴 것 같다.

Low-level API 만을 참조한다. 외부 의존성을 갖지 않는다.

장치 드라이버

파일 시스템이나 인코더/디코더와 같은 소프트웨어적인 도구들 또는, 가속도 센서나 마이크등과 같은 외부 센서용 각종 드라이버.

다음 단계로 나아가기 위한 교두보이자, 사용자 확보에 직접적 영향을 끼친다. 사용자에게 필요한 기능/주변장치를 지원하지 않을 경우 사용자를 잃기 때문이다. 지원하는 장치 드라이버는 많을수록 좋다.

오픈소스를 비롯한 외부 서드파티 라이브러리를 포팅하고 연동하는 일이 주를 이룰 것.

개발 플랫폼 구축

이 단계부터는 다른 사업으로의 확장도 가능해질 것 같다.

AWS IoT EduKit과 같은 하드웨어+소트프웨어 개발킷을 묶음으로 제공하면서 마켓팅과 함께 인지도 높이는 것부터 시작해볼 수 있겠다.

외연 확장 및 통합 솔루션 구축

칩 기반 SDK 에서 플랫폼 기반 SDK 로 사고를 전환해볼 수 있다. Tuya의 IoT 개발 플랫폼 등. 클라우드나 다른 서비스와의 연동을 생각해 볼 수 있다.