STM 보드 고군분투기 - 2. STM Cube IDE 가 복잡한 이유 (tistory.com)
STM을 사용하려는 시도를 한 지 1년이 지났다. 그 동안 마스터했냐 하면, 손도 대지 않고 있었다. 그러다가 현업에서 STM을 사용하게 되었다. 뭔가 감개무량하면서도 걱정이 되었던 것은 벌써 몇 주 전이고, 한참 헤매기를 곧바로 몇 주간 하고 있다.
처음 STM을 활용한 업무에 투입되면서 받은 튜토리얼은 STM의 역사부터 짚고 넘어가는 내용이었다. "왜 이렇게 돌아서 이야기를 풀어가지" 하던 것도 잠시, 얼마 지나지 않아 "아 그렇게 STM이 탄생했구나", "아, 그래서 STM이 쉽구나", "아, STM을 이렇게 쓰면 좋구나" 하는 것을 이해하기 위해서는 STM이 탄생한 배경부터 배우는 것이 중요하다는 것을 깨닫게 되었다. 그동안 했던 고군분투 덕분에 어느 정도 이해력의 바탕이 생겼다는 것도 무시할 수는 없을 테다.
먼저 STM이 무엇이냐? ST Microelectronics사에서 만드는 CPU의 일종이다. CPU를 만드는 회사는 STM 이외에도 TI (Texas Instruments), 르네상스, 도시바, ATMEL (아두이노로 유명하다) 등이 있다. 이 중 르네상스와 도시바는 소매 대응을 하지 않기에 개발 단계에서 사용하기에는 무리가 있다. 결국 로봇 개발자들은 TI와 STM, Atmel 중 하나를 선택하게 되는데, 고사양이 필요하다면 TI와 STM 중에서 고르게 되는 것이다.
이 중 TI는 전통의 강호이다. 나로서는 계산기 만드는 회사 아냐? 하고 생각했던 적도 있지만, 노노. 어디에 구체적으로 사용되는지는 잘 알지 못하지만 아무튼 대단한 CPU 브랜드다. TI를 더 대단하게 만드는 것은 유구한 역사에서 비롯된 Documentation이다. 다양한 사람들이 다양한 시도를 TI CPU를 통해 해왔기에, 구현하려는 기능을 손쉽게 찾아볼 수 있다는 장점이 있다.
그렇게 순조롭게 진행되던 TI의 CPU 장악을 방해한 것은, ARM이라고 하는 processor의 등장이었다. 구체적으로 processor와 CPU의 관계가 어떻게 되는지는 차치하고, ST Microsystems에서 ARM Processor를 활용한 CPU를 발빠르게 내놓기 시작한 것이다. CPU (Central Processing Unit)에서 중요한 것은 단순히 Processor만 있는 것이 아니라, 그 옆에서 부가 기능을 수행하는 Peripheral 이 포함된다. 해당 기능들을 수행함에 있어서 STM은 최적 설계를 통해 전력 소모를 최소화하는 것으로 유명하다.
이번에는 분야를 살짝 바꿔서, Compiler에 대해 이야기해보도록 하자. Compiler란, 코드를 CPU에서 돌아갈 수 있게끔 포장해주는 역할을 하는 프로그램이다. "포장이면 뭐 거기서 거기 아녜요?" 라고 묻는 사람도 있겠지만 노노. 컴파일러의 성능 역시 회사마다 다르다. 가장 유명한 것이 IAR이라는 회사의 Compiler다. 구체적으로 어떤 장점이 있는지는 나도 잘 모르지만, TI와 마찬가지로 오랜 역사를 가진 덕에 많은 Documentation을 확보했고 이는 또 다시 유저를 끌어모으는 역할을 했다. 이외에도 Keil, MDK 등의 Compiler가 존재한다. 하지만 여기서 주목할 회사는 Atolic이라는 회사이다. ST Microelectronics가 인수하기 때문이다. Atolic은 eclipse라는 시스템을 기반으로 하는데, eclipse는 개발 단계와 Debugging 단계, 혹은 peripheral 설정 단계 (뒤에 설명한다) 등을 따로 따로 두는 것으로 유명하다. 이는 내가 STM 보드 고군분투기 - 2. STM Cube IDE 가 복잡한 이유 (tistory.com)에서 어떻게 디버깅을 하는 것인지 헤맸던 이유를 설명해준다.
ST Microelectronics는 Atolic을 인수하여 ST Cube MX라는 프로그램으로 진화시킨다. CPU는, Processor와 Peripheral로 이루어진다고 설명한 바 있다. Peripheral이란, 어떤 속도로 Processor를 사용할 것인지, 어떤 통신 방식을 사용할 것인지 등 모든 부가적인 기능을 통칭한다. 이 Peripheral을 설정하기 위해서 또 다시 코드를 통해 "이 속도로 통신할 거야, 이런 저런 기능을 구현할 거야" 라고 알려줘야 하는데, 이것을 위해 ST Cube MX가 존재하는 것이다. 그림으로 그리면 아래와 같다.
이렇게 되면 이제서야 이해가 간다. "아~ 그래서 ST Cube IDE와 ST Cube MX가 따로 따로 있구나", "아~ MX의 역할은 이런 거구나." 하지만 이제 시작이다. 코드를 올리는 것부터가 아두이노와 방식이 다르고, 코드의 구성은 더 다르다. 하지만 이를 이해하고 블로그에 정리하는 것은 고군분투기 4 혹은 5편에서나 가능할 예정이다. 현재로서는 고군분투가 한창 진행 중이다.
'트렌드 한눈에 보기 > 산업 트렌드' 카테고리의 다른 글
유저 테스트를 하면서 느끼는 점 (1) | 2023.04.26 |
---|---|
실전에서 사용하는 딥러닝 - : IMU 활용 속도 추정 (내 딥러닝이 망한 이유) (0) | 2023.04.20 |
두 편으로 이해하는 칼만 필터의 역사와 원리 - [원리] (0) | 2023.02.19 |
두 편으로 이해하는 칼만 필터의 역사와 원리 - [역사] (0) | 2023.02.19 |
스타트업이 망하면 어떻게 될까? - 망해본 사람들의 이야기 (0) | 2022.07.30 |