카드뉴스
MCU 클럭은 속도 숫자가 아니라 기준 시간입니다
MCU 클럭을 처음 보면 8MHz, 72MHz, 168MHz 같은 숫자부터 눈에 들어옵니다. 하지만 실제 개발에서 더 먼저 볼 점은 그 클럭이 어디서 만들어지고, 어떤 경로를 거쳐 CPU와 주변장치로 전달되는지입니다. 내부 오실레이터, 외부 크리스털, PLL, prescaler, 버스 클럭이 연결되는 흐름을 이해해야 Timer 주기, UART 보드레이트, PWM 주파수, ADC 샘플링 시간이 맞는 이유를 설명할 수 있습니다.
클럭은 MCU 전체가 움직이는 기준 박자입니다. CPU 명령 실행도 클럭을 기준으로 진행되고, Timer 카운터도 클럭 틱을 세며, GPIO나 통신 주변장치의 레지스터 갱신도 결국 이 시간 축 위에서 일어납니다. 그래서 클럭 설정을 바꾸면 단순히 코드가 빨라지는 데서 끝나지 않고, 통신 오차나 인터럽트 주기, 전력 소모까지 같이 바뀔 수 있습니다.
HSE, PLL, prescaler를 한 흐름으로 봐야 합니다
외부 크리스털을 쓰는 HSE는 상대적으로 안정적인 기준 클럭을 만들기 위해 선택하는 경우가 많습니다. 내부 오실레이터는 부품이 줄고 설정이 간단하지만, 온도나 제품군에 따라 정확도 조건을 확인해야 합니다. PLL은 기준 클럭을 곱하거나 나누어 더 높은 시스템 클럭을 만드는 블록이고, prescaler는 그 클럭을 버스나 주변장치에 맞게 다시 나눠주는 역할을 합니다.
STM32 같은 MCU에서 클럭 트리를 보면 SYSCLK, AHB, APB 같은 이름이 함께 등장합니다. 여기서 어떤 Timer가 어느 버스 클럭을 받는지, UART가 어떤 peripheral clock을 기준으로 보드레이트를 계산하는지 확인해야 합니다. 예제 코드가 동작하더라도 CubeMX 설정이나 레지스터 값을 바꾸면 주변장치 계산식이 달라질 수 있으므로, MHz 숫자 하나만 보고 판단하면 놓치는 부분이 생깁니다.
클럭을 올리면 함께 확인할 것이 늘어납니다
클럭을 높이면 처리 성능이 좋아질 수 있지만 항상 정답은 아닙니다. 전류 소모와 발열이 늘 수 있고, 빠른 엣지와 고주파 동작은 EMI나 노이즈 문제를 키울 수 있습니다. 일부 MCU에서는 플래시 메모리 wait state, 전압 스케일, 저전력 모드 조건도 같이 맞춰야 합니다. 데이터시트의 최대 주파수만 보고 설정하기보다 보드 전원, 주변장치 요구 시간, 통신 정확도를 함께 봐야 합니다.
디버깅할 때는 먼저 실제 시스템 클럭이 의도한 값인지 확인하는 것이 좋습니다. MCO 핀으로 클럭을 출력해 오실로스코프로 보거나, Timer 주기와 UART 보드레이트가 계산값과 맞는지 측정하면 설정 오류를 빨리 찾을 수 있습니다. MCU 클럭 공부의 목표는 숫자를 외우는 것이 아니라, 시스템 기준 시간이 어떻게 만들어지고 나뉘어 쓰이는지 읽을 수 있게 되는 것입니다.
주변장치 오류는 클럭 설정에서 시작되는 경우가 많습니다
UART 문자가 깨지거나 PWM 주기가 계산과 다르거나 ADC 샘플 시간이 맞지 않을 때, 코드 로직만 보면 원인을 놓칠 수 있습니다. 실제 peripheral clock이 예제와 다르면 보드레이트 분주값, Timer tick, watchdog 시간도 같이 달라집니다. 특히 저전력 모드에서 특정 클럭 도메인이 꺼지는지, APB prescaler 변경으로 Timer 입력 클럭이 어떻게 바뀌는지 확인해야 합니다. 클럭 트리를 읽는 습관은 주변장치 디버깅의 출발점입니다.
