HW :: 최적의 마이크로컨트롤러 선택 방법

임베디드 컨트롤 프로젝트를 시작할 때는 어떤 마이크로컨트롤러를 사용해야 하는가, 저가의 마이크로컨트롤러를 
선택한 후 마이그레이션해야 하는가, 아니면 하이 엔드 마이크로컨트롤러로 시작한 다음 다운사이징해야 하는가, 
8비트, 16비트, 32비트 MCU 중 어느 것이 필요한가 등의 질문이 나오게 된다. 질문이 다양한 만큼 답도 다양하다. 
여기서는 프로젝트 시 체크해야 하는 요구사항에 대해 정리했다.

 

 

임베디드 컨트롤 프로젝트를 시행할 경우, 다양한 항목에 대해 질문하고, 체크해야 한다. 프로젝트가 어떠한 수준의 컨트롤을 필요로 하는지, 전력 제한은 없는지, 혹독한 환경에서 동작하는지, 어떤 종류의 처리 성능을 요구하는지, 사람과 연결되는지, 또는 다른 시스템과 연결되는지, 변화에 대한 반응 속도는 어떠한지 등 의문점들은 계속해서 나타나므로, 엔지니어가 상황에 따라 세심하게 주의를 기울이지 않을 경우 프로젝트가 마비되어 버린다.
이에 대한 해결책은 모든 요구사항을 수집하여 절충안을 검토하는 것이다. 필자는 개인적으로 프로젝트에 대한 기본 요구사항들을 명확하게 정리한 1∼2 페이지 분량의 문서를 사용한다. 그리고 처음 시작할 때는 해당 프로젝트의 기본적인 기능에서부터 접근한다.

1. 시스템이 어떤 태스크를 수행하는가?
2. 시스템 입력과 출력은 무엇인가?
3. 데이터 스토리지 용량은 얼만큼 필요한가?
4. ‌시스템은 어느 정도로 빨리 태스크를 처리하고  
이벤트에 대응해야 하는가?

표 1은 간단한 온도조절장치를 제어하기 위한 예제 리스트이고, 다음 문서에는 설계상 제약 조건을 포함시켜야 한다.

표 1. 프로젝트 요구사항 예비 리스트

1. 원재료 및 조립에 대한 목표 비용은 얼마인가?
2. 시스템 전력에 관한 요구사항은 무엇인가?
3. 시스템 물리적 크기의 제한사항은 무엇인가?
4. 시스템의 목표 운영 환경은 무엇인가?

표 2는 표 1과 같이 온도조절장치를 제어하기 위한 예시 리스트이다. 이러한 요구사항들이 명확히 정의되면, 시스템에 대한 리소스 요구사항 예비 리스트를 작성할 수 있다.

표 2. 프로젝트 설계 제약 요소

1. 어느 정도의 데이터 RAM이 필요한가?
데이터 메모리 : 165bytes
2. 어느 정도의 프로그램 공간이 필요한가?
플래시 메모리 : 2300words
3. ‌MCU에 필요한 온 칩 주변장치는 무엇이며, 어떤 온 칩 주변장치를 사용하는 것이 좋은가?
주변장치 : ① 필수 확보 사항(LCD 주변장치, USART, ADC), ② 검토 대상[정전용량방식-터치(Cap-touch) 주변장치, 실시간 클록 주변장치]
4. 필요한 다른 신호 조절 또는 제어 회로가 있는가?
외부 회로 : 온도 센서, 와치독 타이머(WDT), 냉·난방을 위한 오픈 컬렉터 드라이버, 전압 레귤레이터
5. 작업 수행 시 어느 정도의 MIPS가 필요한가?
처리 속도 : 500KIPS∼1MIPS

이 시점에서 추정값의 절대적인 정확도에 대해 걱정할 필요는 없다. 이는 대략적인 규모 산출을 위한 것이며, 이후 진행할 트레이드-오프(Trade-off) 분석을 위해 수치적인 근거를 확보한 것이다. 그림 1은 설계 시 필요한 트레이드-오프 관련 결정 사항을 나타낸 것이다.
여기서 그림 1의 차트에 8비트∼32비트 영역까지 있다는 데 주목하자. 기본 개념은 나열된 각 항목이 한쪽에서 다른 쪽으로 이어지는 연속체라는 것이다. 이는 양쪽의 극한값이 다른 쪽에서는 불가능하다는 것을 의미하는 것이 아니라, 단지 해당 영역에서 구현하기가 상대적으로 쉽다는 뜻이다.
예를 들어, 실시간 응답(Real-Time Response)은 차트의 8비트 영역에 있는 반면, RTOS는 32비트 영역에 있다. 이것은 8비트 마이크로컨트롤러용으로 사용할 수 있는 RTOS 솔루션이 없다는 의미가 아니라, RTOS는 16비트 및 32비트 영역에서 더 일반적이며 16비트 및 32비트 마이크로컨트롤러에서 메모리 풋프린트가 상대적으로 작다는 뜻이다.

 ‌하드웨어와 소프트웨어

먼저 리스트의 첫 번째 항목인 하드웨어와 소프트웨어를 비교해 보자(질문을 디지털 주변장치로 제한하고, 아날로그 주변장치에 대해서는 다음에 다시 논의한다). 이 질문은 설계와 거리가 있다. 우선, 필요한 기능의 일부 또는 모두를 소프트웨어상에서 개발할 것인지, 하드웨어를 사용할 것인지 생각해야 한다. 트레이드-오프는 처리 성능과 하드웨어 복잡성 사이에 있다. 예를 들어, ‘소프트웨어 기반 스테퍼 모터 컨트롤러를 구현해야 하는가 아니면 컨트롤러 칩을 사용해야 하는가’라는 질문의 답에 따라 프로세서 속도 요구사항, 프로그램 메모리 요구사항, 시스템 비용, 보드 크기, 그리고 아마도 전류 소모량까지 영향을 받게 될 것이다.
물론 보이지 않는 제약이 있을 수도 있다. 예를 들어, USART 기능을 소프트웨어로 구성하는 것은 전송과 수신 기능 모두를 소프트웨어로 에뮬레이션할 수 있으므로 상당히 합리적이다. 문제는 수신 기능이 수신 타이밍을 정확히 동기화하기 위해 스타트 비트의 하강 에지에 대해 지속적으로 폴링해야 한다는 것이다. 이로 인해 처리 성능을 허비할 수 있다. 인터럽트 온 체인지 기능을 이용하더라도 인터럽트 서비스 루틴의 지연 시간에 의해 에지의 타이밍 정확도에 문제가 생길 수 있다. 따라서 하드웨어 주변장치를 소프트웨어 기반 대체품으로 전환할 경우에는 숨겨진 제약사항에 주의해야 한다. 이제 선택 가능한 사항을 확인한 후 잠재적 비용에 대해 알아보자.

 ‌실시간 응답과 RTOS

이 트레이드-오프는 프로젝트의 소프트웨어 설계와 유사한 의사 결정에 관한 것으로, 실시간 응답과 실시간 운영 체제(RTOS)가 이에 해당한다. 이 경우 멀티-태스크를 설계에서 어떻게 처리할지 결정해야 한다. 실시간 운영 체제를 사용할 것인가. 아니면 인터리브 상태 머신 외부에 시스템을 구축할 것인가. 두 방법 모두 장점을 갖고 있다.
RTOS는 상태 간 모든 스위칭을 처리하며 소프트웨어 설계를 단순화시킬 수 있는 반면, 실시간 응답 시스템은 메모리 풋프린트 요구사항이 상대적으로 작고, 실시간 응답 제어를 보다 쉽게 구현할 수 있다. 두 선택 모두 데이터/프로그래밍 메모리 요구사항에 다소 영향을 미치며, 시스템에 요구되는 처리 성능에 대해서도 잠정적으로 영향을 줄 수 있다.
또 다른 잠재적인 문제는 RTOS의 타입에 따라 발생할 수도 있다. RTOS는 2개의 기본 범주, 즉 우선권 부여 방식(Preemptive)과 협력 방식(Cooperative)으로 구분할 수 있다. 두 가지 모두 다중 태스크 사이에서 스위칭이 가능하지만, 스위칭 트리거에 차이가 있다. 이로 인해 가변적인 스토리지와 주변장치에 대한 요구사항이 달라지므로 이를 시스템 요구사항에 반영해야 한다.

 ‌대기 전력과 동적 파워 제어

그림 1. 시스템 트레이드-오프

또 다른 하드웨어 결정사항은 시스템 전력 요구사항, 즉 대기 전력/동적 파워 제어와 관련되어 있다. 이 경우 전량 배분(All-or-nothing) 방식으로 전류 소모를 제어할 것인지, 아니면 설계 일부 영역만 오프 상태로 전환할 수 있는 단계적인 시스템을 사용할 것인지를 결정해야 한다. 둘 다 설계에 사용할 수 있으며, 이 경우 하드웨어·소프트웨어 비교 부분에서 결정한 결과에 따라 영향을 크게 받는다.
이것은 기본적으로 시스템 유휴 태스크를 처리하기 위해 시스템의 일부를 깨어 있는 상태로 유지하며 전류를 소모하도록 해야 하는가. 아니면 프로세서를 슬립 상태로 두고 낮은 대기 전류를 소모하면서 간단한 태스크들을 처리할 수 있는 자동 하드웨어 시스템을 가져야 하는가의 문제이다.

 

‌전기적으로 강력한 설계

이 부분은 전기적으로 강력한 설계의 필요성에 관해 질문한다. 모든 설계들이 전기적으로 강력해야 하지만, 이 경우 강력함을 실현할 수 있는 방법에 대해 트레이드 오프가 발생할 수 있다. 이 문제는 전력 및 하드웨어·소프트웨어 질문과 전부 연관된다. 
일례로 전력-변환 기능에 대해 살펴보자. 첫 번째 옵션은 소프트웨어 중심적인 설계를 사용하는 것으로, 피드백 제어를 생성하기 위해 소프트웨어 기능을 사용한다. 두 번째 옵션은 더 단순한 아날로그 피드백 PWM을 사용하는 연산 증폭기(OP Amp) 기반 루프 필터를 사용한다. 두 시스템 모두 현재 현장에서 사용되고 있다. 이 둘의 차이점은, 전력 컨버터가 동작하는 동안 소프트웨어 기반 시스템이 액티브 상태를 유지해야 하며, 이로 인해 상대적으로 높은 동작 전류가 필요할 수 있다는 점이다.
그리고 마이크로컨트롤러의 프로그램 카운터에 고장이 발생했을 때 하드웨어 기반 시스템은 마이크로컨트롤러 복구 기능에 의해 영향을 받지 않으므로, 노이즈가 많은 환경에서도 전기적으로 강력해질 수 있다.

 ‌

아날로그 신호 체인과 연산

다섯 번째 항목은 다시 하드웨어·소프트웨어에 대한 질문이지만, 여기서는 아날로그 신호 체인과 연산(예를 들면 DSP)을 사용하는 것에 대한 부분이라고 할 수 있다. 여기서 트레이드-오프는 시스템 제어와 관련해 발생한다.
‘입력 신호 조정과 출력 생성을 위해 아날로그 신호 체인을 사용할 것인가? 아니면 소프트웨어를 사용할 것인가?’ 이 질문의 해답은 앞서 언급한 하드웨어와 소프트웨어에 대한 질문보다 더욱 더 불분명하다. 그리고 이 질문은 마이크로컨트롤러 선택 시 더 큰 영향을 미친다. 비례·적분·미분(PID) 기능 또는 디지털-필터 설계를 구현하려면 마이크로컨트롤러가 반드시 두 가지 온 칩 기능을 제공해야 한다. 첫 번째는 피드백과 제어를 위한 시스템 요구사항을 충족시키는 하드웨어 곱셈 기능이고, 두 번째는 고속 및 고해상도 ADC이다.
이러한 기능들 없이도 마이크로컨트롤러를 사용하여 일부 간단한 피드백 제어를 구현할 수 있지만, 속도가 느릴 뿐 아니라 태스크 수행을 위해 사용할 수 있는 처리 성능을 전부 사용해버린다. 이 경우, 필수 기능 수행을 위해 아날로그 시스템을 사용하는 것이 훨씬 간단하며, 이때 마이크로컨트롤러는 감독하는 역할을 수행한다. 
그러나 일부 기능들은 보다 높은 속도를 요구하며, 아날로그로 실행이 어렵거나 불가능한 비선형 피드백 제어, 무한 임펄스 응답(IIR) 필터 등에 해당된다. 이 경우 거의 유일한 옵션은 아날로그 고장-감지 회로와 함께 소프트웨어 솔루션을 사용하는 것이다.

 ‌

실제 환경과 어드밴스 머신

최종 트레이드-오프는 사용에 관한 것이다. ‘제한된 시스템의 사용자 인터페이스만 제공하는 소형 자동 제어인가? 또는 네트워킹 기능과 보다 복잡한 사용자 인터페이스를 제공하는 고급 시스템인가?’ 분명한 것은 9.99달러짜리 가정용 온도조절장치의 제어 기능을 구현하기 위해 터치스크린이 내장된 QVGA를 사용하지는 않는다는 것이다. 하지만, 대형 오피스 빌딩 환경 제어 시스템에 네트워크로 연결된 시스템인 경우, 이 사용자 인터페이스가 필요할 수도 있다. 사실 이것은 사용자 인터페이스에 대해 어느 정도의 대역폭이 요구되는지, 그리고 어떤 연결 기능이 필요한지에 대한 질문이다. 또한 시장에는 심미적인 룩 앤드 필 트렌드에 따르기 위한 요구사항이 있을 수 있다. 시스템의 복잡함을 결정하려면 이 모든 요구사항을 고려해야 한다.
모든 트레이드-오프 사항을 고려해 시스템 리소스 요건을 적절하게 조정했다면, 이제 카탈로그에서 적절한 마이크로컨트롤러를 찾아야 한다. 마이크로칩 테크놀로지에서는 처리 성능, 메모리(플래시 및 RAM), 주변장치 믹스 등을 고려하여 올바른 솔루션을 제시한다.
정확하게 일치하는 것을 찾지 못할 수도 있다. 이 경우 확실히 트레이드-오프 사항들을 재확인하고 몇 가지 어려운 선택도 해야 한다. 이것이 바로 어떤 주변장치가 검토 대상이며 필수 확보 사항인지 설명했던 이유이다.
필자가 할 수 있는 실질적인 충고는 상·하위 호환성이 있는 제품군의 마이크로컨트롤러를 찾아야 한다는 것이다. 기능을 추가하거나 비용을 절감하기 위해 메모리 또는 주변장치를 추가 및 제거할 경우에는 선택의 여지가 넓어진다. 각 기능과 관련된 반도체 및 테스트 비용이 존재하며, 선택에 따라 각 비용이 추가된다. 일부 기능들은 더 높은 비용을 필요로 한다. 
따라서 최종 제품을 선택하기 위해 옵션을 좁혀 나갈 때는 리스트에 있는 필수 확보 사항과 검토 대상을 다시 한 번 살펴보는 것이 좋다. 비용 및 설계 도구의 복잡성 역시 고려해야 한다. 설계자 뿐만 아니라 최종 제품을 제작하는 지원, 테스트, 생산 직원들을 위해 이러한 툴을 구매해야 하는 것이다.

 

‌기타 고려 사항

이 밖에 설계 시 고려해야 할 사항으로, 사전에 구축된 스택 및 라이브러리 기능이 제공되는가 하는 부분이 있다. 일부 제조업체는 그래픽 디스플레이 드라이버, 직렬 통신 기능, 정전용량식 터치 기능 등의 특정 기능을 위해 사용 가능한 사전 구축 코드를 제공한다. 이러한 표준 블록을 통해 시간과 테스트 과정을 줄일 수 있지만, 이 경우 해당 블록이 설계와 호환되는지 반드시 확인해야 한다. 예를 들어 일부 블록은 하나 이상의 주변장치를 독점적으로 사용하여 다른 기능을 액세스할 수 없는 경우도 있다. 시스템 내 다른 기능과 충돌하는 타이밍 요구사항이 존재할 수 있으므로, 프리팹 코드(Prefab Code) 사용 전에 반드시 특정 질문들을 해야 한다.
또한 최종 결정 시 코드 재사용을 고려해야 한다는 점도 매우 중요하다. 그렇다고 모든 설계에 대해 처음부터 다시 접근할 필요는 없다. 다양한 마이크로컨트롤러를 생산하고 이를 지속적으로 제공하는 제조업체를 찾으면 된다. 이를 통해 향후 설계에서 개발해야 할 많은 부분을 재사용함으로써 개발 및 테스트 기간을 줄일 수 있다. 또한 너무 다양한 제조업체의 도구 및 부품을 사용하면 테스트, 지원 및 생산 인력에 부담을 줄 수도 있다.

Keith Curtis / Microchip Technology Inc.

출처 : 첨단 http://www.hellot.net/