8비트 MCU 또는 32비트 MCU 선택 기준

이 글은 8비트 MCU와 32비트 MCU를 선택하는 데 있어 버스 폭이 MCU의 선택 기준이 될 수 없는 이유에 대해 설명하고자 한다. 임베디드 개발자들은 마이크로컨트롤러에 대해 광범위한 선택을 할 수 있지만 버스 폭이 반드시 성능별로 단계적인 기준으로 적용되지 않기 때문이다. 

반도체 제조업체가 32비트 아키텍처를 마이크로컨트롤러에 포팅하기 시작하면서 엔지니어링 커뮤니티에서는 8비트 디바이스가 사라질 것이라는 예측도 있었다. 사실, 8비트 디바이스가 적용된 기기의 사용은 감소해 왔으며 더 이상 시장을 주도하는 위치도 아니다.

그러나 8비트가 사라지기에는 아직도 먼 이야기다. 실제 32비트 제품을 제공하고 있는 제조업체들도 여전히 8비트 제품군을 개발 및 확대하고 있기 때문이다.

8비트와 32비트 MCU 중 한 가지를 선택해야 하는 논쟁을 둘러싼 혼란은 실제로 두 MCU의 유연성 유무다.

결론적으로 MCU 하나는 다양한 애플리케이션에 사용될 수 있다. 그러나 MCU가 그렇게 유연하게 설계됐다면 왜 아직도 그렇게 많은 변형체들이 존재할까? 이에 대한 수많은 답변은 코어보다 페리페럴에서 찾아야 한다. 하지만 사실 코어와 페리페럴도 서로 떼어놓을 수 없는 관계다.

또한 8비트 아키텍처가 32비트와 비교해 진부하다고 생각할 수 있지만 현실은 또 다시 놀라울 정도로 다르다. 명령어 셋트가 적합하게 구성되는 반면 대부분의 8비트 코어는 수명 기간 동안 한 번 이상 ‘페이스 리프트(face lift)’를 겪는다.

또한 다른 디바이스들처럼 제조 기술 발전의 혜택도 누리고 있다. 따라서 이러한 관점에서 동등하게 2가지의 MCU를 다루는 것이 공평할 것이다.
  
기본적 차이
현저한 버스 폭 차이와 별도로 8비트 디바이스는 특히 평균 판매가격에 영향을 줄 수 있는 코어에 통합되는 메모리 용량 측면에서 일반적으로 32비트 디바이스보다 훨씬 더 작다.

하지만 LCD 컨트롤러·드라이버 등 시스템급 기능으로 완전히 통합해야 할 경우 32비트 솔루션에서 실현될 가능성이 훨씬 높다. 

매우 일반적인 관점에서 시스템이 65킬로바이트(kbyte) 이상의 코드 메모리가 필요한 경우 32비트 솔루션을 선택할 것이다. 반면 요건이 8킬로바이트 정도로 낮을 경우 8비트 솔루션으로 선택될 가능성이 더 높을 것이다.

물론 본질적으로 8비트 디바이스는 단순한 작동에 적합해 더 적은 코드 공간을 요구하지만 32비트 명령어 셋트는 한 개 명령어로 더 많은 작업을 수행할 성능을 갖추고 있기 때문에 애플리케이션이 커지고 복잡해질수록 더욱 복잡한 명령어 셋트가 전반적으로 더욱 우수한 코드 밀도를 구현할 수 있을 것이다.

두 가지의 극단 사이 어딘가에 코드 베이스가 있는 애플리케이션이거나 혹은 ‘표준’ MCU 주변기기만 필요한 애플리케이션의 경우 선택은 모호해지며 결정은 실제 애플리케이션을 기준으로 이뤄져야 한다. 기술자들은 애플리케이션 프로파일링에 어느 정도 시간을 투자해서 어떤 아키텍처가 자신들의 요구를 가장 잘 충족하는지를 신속하게 확신할 수 있다.

기본 성능
물론 대부분의 기술자들이 8비트와 32비트의 차이로 지적하는 주요 항목 중 하나는 총 성능이지만 이와 같은 성능은 실제 특정 요구 사항과 비교해 정량화할 수밖에 없다. 실제로 이것은 실현 가능한 성능에 대한 문제다. 

예를 들면 코어텍스-M0+와 8051을 비교해 보자. 코어텍스-M0+는 8비트 애플리케이션 공간을 목표로 한 아키텍처로서 임베디드 공간에 구현이 가능하기 때문에 대부분의 엔지니어들이 직면할 수 있는 문제다. 직접적인 데이터 시트 비교는 전후 관계상 무의미할 것이다.
 
코어텍스-M0+ 기기가 대부분 ‘우수’하겠지만 실제 상황에서 결과는 상당히 다를 수 있다.

대용량 코어의 특성은 리소스를 부주의하게 사용하는 것이다. 이것은 임베디드 시스템의 경우 8비트 아키텍처 설계자들이 지금까지 피해왔던 우려 사항의 원인이다.

예를 들어 [그림1]의 코드를 살펴보자. 코어텍스-M0+ 기반 기기에서 컴파일하고 실행하는 경우 스택은 48바이트를 필요로 하지만 8051에서 컴파일하고 실행하는 경우 16바이트만 필요로 한다. 큰 차이는 없지만 RAM이 제한된 시스템의 경우 더 중요할 수 있다.

8051 원래 설계 중 한 개 레거시는 통합되지 않은 메모리 맵이다. 대부분의 경우 메모리 맵은 플래시, 내장 RAM, 외장 메모리 등 다양한 메모리 종류에 서로 다른 명령어를 사용하면서 효율성을 제공할 수 있다.

그러나 명령어 셋트는 모든 종류의 메모리에 적용될 수 있는 일반적인 지시자(pointer) 사용을 가능하게 하며 이에 따라 다소 효율성이 낮은 실행 비용으로 코드 재활용성을 향상시킬 수 있다. ARM 아키텍처는 통합된 메모리를 가지고 있으며 이것은 특정 지시자가 필요 없고 이에 따라 작업이 더욱 단순화될 수 있다는 것을 의미한다.

임베디드 개발자들이 고민하는 문제는 바로 비효율성이며 비효율성을 없애기 위해 할 수 있는 모든 것을 시도할 것이다. 이것은 다른 우려 사항인 지연 속도(latency)로 주목시킨다.

직관적으로 엔지니어들은 코어텍스-M0+가 인터럽트와 함수 호출 대응시간이 더 빠르다고 생각할 수 있지만 실제 8051 아키텍처가 더 빠르며 이것은 주변기기가 AMBA 고성능 Bus(AHB)를 통해 고급주변기기버스(APB)로 ARM 코어에 접근할 수 있다는 사실로 더욱 명확해 진다.

이에 따라 단순 시스템에서 8051은 인터럽트 서비스 루틴 입출력시간에서 장점이 있지만 실행 시간이 더 긴 더욱 복잡한 시스템이나 서비스 루틴의 경우 이와 같은 장점이 빠르게 사라질 수 있다.

애플리케이션 활용성
8비트와 32비트 코어, 특히 8051과 코어텍스-M0+의 또 다른 중요한 일반적인 차이는 제어 작업 수행과 관련된 본질적인 강점과 약점이다. 8051 명령어 셋트는 비트와 바이트를 이동시키는데 우수하지만 코어텍스-M 아키텍처의 강점은 더 큰 데이터 블록을 스트리밍하거나 광범위한 수학 함수를 사용해서 복잡한 알고리즘을 수행할 때 나타난다.

‘제어 vs 프로세싱’ 비교는 특히 어떤 아키텍처가 애플리케이션에 가장 적합한지를 선택할 때 유용할 수 있지만 어렵고 신속한 규칙은 아니다.

주로 UART에서 SPI 브릿지를 실행하는 애플리케이션이 ARM 기기에서 더욱 효율적으로 실행될 수 있지만 8비트 디바이스는 간단하게 처리할 수 있으며 2킬로바이트 정도로 작은 통합 메모리를 사용하는 기기에게 가장 적합할 것이다.

예를 들어 32비트 수학 함수를 수행하기 위해 10%의 시간을 사용하고 제어 기능을 수행하는데 25%의 시간을 수행하며 나머지 65% 처리 시간을 일반적인 목적의 작업을 수행하는 애플리케이션을 생각해 보자.

명확하게 우선시되는 아키텍처는 없으며 실행 속도보다 더 작은 코드 공간에 대한 시스템 수준 요구 사항을 함께 고려하는 경우 8비트 변형체가 적합할 수 있다. 하지만 실행 속도가 최우선이라면 32비트를 선택할 가능성이 높다.

총전력 소비 평가도 이와 유사한 비교가 될 수 있다. 실리콘랩스와 같은 대부분 공급업체들은 자신들의 포트폴리오에 8비트와 32비트 디바이스를 모두 사용하고 있는 기술자들이 이와 같은 변수를 평가하는데 도움을 줄 수 있는 하드웨어와 소프트웨어 툴을 제공하고 있다.

결론적으로 대안으로써 8비트 또는 32비트 선택이 해당 애플리케이션에 명백한 혜택으로 다가 오지 않는다면 ‘잘못된 선택’으로 발생할 수 있는 심각한 피해를 경험하지 않을 수 있게 된다.

8비트 아키텍처는 임베디드 개발에서 중요한 역할을 수행하고 있으며 향후 얼마 동안은 엔지니어들이 한 개의 공통 아키텍처에 디폴트로 사용하는 대신에 옵션을 신중하게 평가할 수 있는 기준이 될 것 같다.