임베디드 학습 저장소

목적 : Zephyr를 통한 LED 제어하기

STM32H573I-DK 보드에는 다음과 같이 4개의 LED (LD1, LD2, LD3, LD4)가 존재한다.

사용에 필요한 LED IO 들이 Device Tree에 설정되어 있는지 확인이 필요하다.

아래 파일의 경우 ST에서 작성해둔 파일로 보드 개발 시, 본 내용을 참조 변경하면 될 것으로 판단 된다.

(본인도 Device Tree 경험이 없지만.. Zephyr를 활용 하려면 Device Tree에 대한 이해가 요구된다..)

# zephyrproject/zephyr/boards/arm/stm32h573i_dk/stm32h573i_dk.dts

해당 파일을 참조해보면, 아래와 같이 정의 되어 있다.

다음과 같은 설정이 있으면, 이제부터 IO 제어를 할 수 있는 구성이 완료 된다.

leds {
		compatible = "gpio-leds";
		green_led_0: led_1 {
			gpios = <&gpioi 9 GPIO_ACTIVE_LOW>;
			label = "User LD1";
		};
		orange_led_0: led_2 {
			gpios = <&gpioi 8 GPIO_ACTIVE_LOW>;
			label = "User LD2";
		};
		red_led_0: led_3 {
			gpios = <&gpiof 1 GPIO_ACTIVE_LOW>;
			label = "User LD3";
		};
		blue_led_0: led_4 {
			gpios = <&gpiof 4 GPIO_ACTIVE_LOW>;
			label = "User LD4";
		};
	};

추가적으로 Device Tree 파일을 보면 aliases 라는 기능을 통해서도 사용이 가능하기 때문에 함께 예제를 통해 알아보고자 한다.

aliases {
		led0 = &blue_led_0;
		sw0 = &user_button;
		watchdog0 = &iwdg;
		spi-flash0 = &mx25lm51245;
		die-temp0 = &die_temp;
		volt-sensor0 = &vref;
		volt-sensor1 = &vbat;
	};

아래 설명에 대한 상세 코드는 아래 링크 참조

https://github.com/HY-PARK/ZephyrStudy

IO를 사용하기 위해서는 prj.conf 파일 내, 아래와 같은 설정이 요구된다.

CONFIG_GPIO=y

사실 아래 명시된 파일에, 이미 CONFIG_GPIO에 대한 설정이 켜져 있어서, prj.con에 설정이 있으나 없으나 동일하다.

(stm32h573i_dk_defconfig에 CONFIG_GPIO 라인을 주석 처리 후 빌드 수행해길 추천한다.)

# zephyrproject/zephyr/boards/arm/stm32h573i_dk/stm32h573i_dk_defconfig

Device Binding을 활용하려면, 아래와 같이 사용을 해야한다.

서두에 언급한 것처럼 Device Tree에서 정의된 label 을 활용하거나, label을 aliase한 정보를 사용한다.

• label 활용 시, DT_NODELABEL
• label aliase 활용 시, DT_ALIAS

GPIO_DT_SPEC_GET을 통해, Device Tree에 정의된 IO들을 제어할 수 있는 객체를 획득하게 된다.

#define LD1_NODE DT_NODELABEL(green_led_0)
#define LD2_NODE DT_NODELABEL(orange_led_0)
#define LD3_NODE DT_NODELABEL(red_led_0)

#define LD4_NODE DT_ALIAS(led0)

static const struct gpio_dt_spec ld1 = GPIO_DT_SPEC_GET(LD1_NODE, gpios);
static const struct gpio_dt_spec ld2 = GPIO_DT_SPEC_GET(LD2_NODE, gpios);
static const struct gpio_dt_spec ld3 = GPIO_DT_SPEC_GET(LD3_NODE, gpios);
static const struct gpio_dt_spec ld4 = GPIO_DT_SPEC_GET(LD4_NODE, gpios);

gpio_pin_configure_dt를 통해 OUPUT 설정을 수행한다.

gpio_pin_toggle_dt를 통해 IO를 토글한다.

int main(void)
{
	gpio_pin_configure_dt(&ld1, GPIO_OUTPUT_ACTIVE);
	gpio_pin_configure_dt(&ld2, GPIO_OUTPUT_ACTIVE);
	gpio_pin_configure_dt(&ld3, GPIO_OUTPUT_ACTIVE);
	gpio_pin_configure_dt(&ld4, GPIO_OUTPUT_ACTIVE);


	while (1) {
		gpio_pin_toggle_dt(&ld1);
		gpio_pin_toggle_dt(&ld2);
		gpio_pin_toggle_dt(&ld3);
		gpio_pin_toggle_dt(&ld4);
		k_msleep(SLEEP_TIME_MS);
	}
	return 0;
}

1. 들어가면서

지난 포스팅에서는 UART TX에 대해 살펴보았습니다.

이번에는 포스팅은 RX 처리 방식과 지난 TX 처리 방식과 조합하여 Echo기능을 보여드리겠습니다.

개발자라면 누구나 그렇듯 RX 데이터는 Polling 방식으로 처리하는 경우나 드물다고 생각합니다.

첫 번째 이유는 다른 Logic을 처리하다 보면 놓치는 데이터가 다분할 것이고,

두 번째는 데이터가 들어올 때까지 마냥 기다리고 있다면 CPU 자원의 낭비이기 때문입니다. 

그래서 가장 일반적인 형태는 Interrupt로 수신된 데이터를 Queue에다가 전부 저장하고,

이후에 Parsing하여 데이터를 처리하는 것이라고 생각합니다.

하지만 Stream 데이터가 계속적으로 들어오는 상황에서는 Interrupt + Queue 방식은 적합하지 않습니다.

그 이유는 계속 ISR 진입이 발생하고, 계속적인 Over Head가 발생하게 됩니다.

그래서 최근에는 Interrupt + DMA 기법들을 많이 사용합니다만, 저는 실 구현 상황에서는 사용해보지는 않았습니다....

(부끄럽네요)

이러한 RX 처리 기법에 대한 부분은 다른 포스팅에서 상세히 다뤄보고, 이번 포스팅은 단순한 RX API 활용에 대해서만 알아보겠습니다.

2. 시작합니다.

지난번 생성한 UART 프로젝트를 계속 활용하는 것이기에 동일한 내용에 대해서는 언급하지 않겠습니다.

1. 코드 구현

UART RX를 처리하기 위해 두 가지 API가 존재합니다.

• UART_ReceiveDataBlocking

• UART_ReceiveData

TX와 마찬가지로 두 API 모두 Interrupt에서 처리가 됩니다. (내부 API를 살펴보면, 동일한 API를 호출하고 있습니다.)

차이점은 ReceiveDataBlocking은 Timout이 발생하거나, 지정된 길이만큼의 Data를 수신하였을 때 함수가 종료되고, 
ReceiveData는 Blocking은 되지 않습니다. 

마찬가지로, ReceiveData 사용 시 이전에 ReceiveData 처리가 완료되지 않은 상황에서 함수를 재 호출하면 동작에 문제가 발생하게 됩니다.

• UART_ReceiveDataBloking을 활용한 Echo 기능 (Polling 방식)

Blocking API를 사용하여, 1초 이내 1Byte를 수신하면 같은 데이터를 전송하고 수신하지 못하면 Timeout이 발생하도록 설정하였습니다.

결과는 다음과 같습니다.

정상적으로 Echo가 되는 것을 볼 수 있으며, 1초 내 데이터가 수신되지 않으면 TIMEOUT이 발생하는 것을 볼 수 있습니다.

왼쪽의 시간표시는 제가 터미널 상 TimeStamp를 찍도록 설정하였습니다.

• UART_ReceiveData를 활용한 Echo 기능 (Interrupt 방식)

(제목 옆에다가 Interrupt 방식을 쓰면서도 고민을 했습니다... 둘 다 Interrupt 베이스로 처리가 되는데... Async/Sync가 더 맞는 거 같은데.. 좀 더 직관적인 표현을 위해 Polling Interrupt로 유지하겠습니다. API 내부를 자세하게 살펴보시면 어떤 의미인지 이해가 되실 거라고 생각합니다.)

Interrupt 처리를 위해서는 RxCallback 등록이 선행되어야 합니다.

Timer에서는 RxCallback 등록 API가 존재하였는데.. UART는 별도로 존재하지 않아, Processor Expert를 통해 등록하여야 합니다.

uart_pal1을 더블 클릭하여, Processor Expert 창을 켭니다.

아래 사진처럼 RxCallback로 사용할 함수 이름을 작성합니다. (해당 이름은 사용자가 임의로 지정합니다.)

설정이 변경되었으니, Code를 재생성합니다.

이후 UART_ReceiveData API를 통해 1byte 데이터 수신을 지정합니다.

다음으로는 Processor Expert에서 지정한 이름으로, CallBack 함수를 정의합니다.

해당 함수는 UART_ReceiveData에서 지정한 크기만큼의 데이터가 수신되었을 때도 호출되지만 다른 Error 상황에서도 호출됩니다.

그래서 각 상황에 따라 개별 로직이 필요하며 현재는 데이터 수신 Event 처리를 위한 로직만 작성하였습니다.

해당 callback에서 가장 중요한 부분은 UART_SetRxBuffer입니다. 데이터를 계속 받고 싶다면 반드시 호출해야 하는 함수입니다.

그 이유 설명하기 전 아래 Call Stack 구조를 먼저 보겠습니다. 

정의한 callback 함수는 LPUART_DRV_RxIrqHandler에서 호출됩니다.

LPUART_DRV_RxIrqHandler를 보면, 빨간 네모 박스 부분이 먼저 호출됩니다.

즉, 해당 라인을 통해 callback 함수도 호출됩니다.

만약 callback 함수 내에서 UART_SetRxBuffer 함수를 호출하지 않으면 노란 네모 박스 부분이 동작하게 되고 모든 Rx 처리에 대한 동작을 중단하도록 되어있습니다.

결과는 아래와 같습니다.

3. 나갑니다.

간단하게 Rx 처리 방식에 대해 알아보았습니다.

저도 맨 처음 UART RX를 쓸 때, SetRxBuffer API에 대해 정확하게 이해하지 못하고 다른 방식으로 처리하다가 내부 API를 자세하게 보면서 잘 못쓰고 있다는 것은 알게 되었습니다.

저같이 실수하시는 분이 없기를 바라며 도움이 되는 포스팅이었으면 좋겠습니다.

다음 포스팅에서는 마찬가지로 Register 설정에 대해 좀 더 자세히 살펴보도록 하겠습니다.

1. 들어가면서

저는 펌웨어를 개발을 할 때, LED Control 이후 먼저 활성화 기능이 UART입니다.

UART는 PC에서 실제 데이터를 확인하거나 외부에서 제어 하기 가장 간편한 방법이기 때문입니다.

최근 ECU를 개발하면서 UART를 외부로 만들어 놓지 않은 경우가 있어
최근에는 Jlink의 RTT를 대안으로 사용하기도 합니다. 나중에 Jlink RTT도 한번 다뤄보겠습니다.

UART를 활용한 Echo에 대해 알아보겠습니다.

(실제 구현 코드는 아래에서 다운로드하시면 됩니다.)

2. 시작합니다.

1. Peripheral Abstraction Layer의 uart_pal 추가

uart_pal을 더블 클릭하여, 사용 Component를 추가합니다. 

S32K146에는 총 3개의 UART 모듈이 존재하고 있고, 각각 개별 설정이 가능합니다.

회로도를 참고하여 어떤 UART를 사용가능한지 확인하겠습니다.

아래 그림에서 볼수 있듯, OpenSDA를 통해 PC와 UART 통신이 가능합니다.

제 PC 상에서는 NXP Board를 연결하면, COM3으로 인식이 됩니다.

또한, 회로도 상에서 UART 1번이 OpenSDA와 연결되어 있는 것을 확인하였습니다.

2. UART Components 설정

좌측 하단의 uart_pal Components를 더블 클릭하여, 설정 창을 Open 합니다.

상단 회로도에서 확인하였듯, UART1번으로 Device를 설정합니다.

기본적인 RX/TX 동작만 보는 것이기에 기본 생성 부분에서, 특별하게 수정하지는 않았습니다.

현재 Baudrate 설정은 9600bps 입니다.

2. IO / CLOCK 설정 확인

다시 회로도로 돌아와서, UART1을 PTC6/7번을 통해 사용되는 것을 확인하였습니다.

좌측 하단의 pin_mux Component를 더블 클릭하여, 설정 창을 Open 합니다.

UART1번에 GPIO 6/7이 설정이 되어있는지 확인합니다.

(Transmit Data의 IO는 I/O 설정이 가능하여, 왜 그럴까 찾아보니 Single Wire 통신을 위한 부분입니다.)

CLOCK도 기본 설정으로 사용하였습니다.

(현재 Baudrate 설정이 9600으로 되어있지만, 실제 Baudrate는 9608로 됩니다. 통신 상 Error율을 줄이기 위해서는 Clock조정이 필요합니다.)

3. 코드 구현

Clock 초기화와 Gpio 초기화는 기존 방법과 같아, 별도의 설명은 추가하지 않았습니다.

첫번째로 Uart 초기화 및 Tx에 대해 알아보겠습니다.

Uart 초기화를 위해서는 아래 API를 사용해야합니다.

• UART_Init

  -> Processor Expert에서 설정 값 기반으로 Register 세팅을 합니다.

이후, Uart Tx를 위해서는 2가지 종류의 API가 있습니다.

• UART_SendDataBlocking

• UART_SendData

해당 두 API 모두 인터럽트 기반으로 TX를 하도록 API가 구현되어 있고, 차이점이라면

SendDataBlocking API 같은 경우에는 Timeout 또는 정상적으로 TX가 완료되었을 때, 함수가 종료됩니다.

SendData는 호출 후 Blocking은 되지 않으나, 기존에 호출하던 데이터 전송이 끝나기 전 SendData를 재호출하게 된다면 정상적으로 원하는 데이터 전송이 되지 않습니다. 즉, SendData 호출 전 상태를 확인하는 루틴이 필요합니다.

(Blocking API는 Polling 방식과 유사해보나, Interrupt를 활용한다는 점에 흥미로웠습니다.
일반적으로 제가 생각하는 Polling은 Tx Register를 계속 확인하는 것으로 생각하였기 때문입니다.)

저는 UART TX 코드 구현 시,  Polling 방식을 선호하기에 Blocking API를 사용하였습니다.

실제 구현 코드는 아래와 같습니다.

Terminal 결과는 다음과 같습니다.

위에서 언급했던 SendData와 SendDataBlocking을 단순하게 반복적으로 호출하였을 때, 어떤 점이 다른지 보여드리겠습니다.

변수를 +1 씩 증가하도록 설정하여, 해당 변수의 값을 SendDataBlocking으로 보내는 코드입니다.

결과는 다음과 같습니다.

특별하게 중간에 데이터가 빠지거나 하는 모습은 보이지 않습니다.

SendData로 보내는 코드입니다.

결과는 다음과 같습니다.

데이터가 깨져서 전송되고 있는 것이 확인 가능합니다. 즉, SendData API를 사용할 때는 주의를 필요로 합니다.

3. 나갑니다.

LED Controll 코드 구현 과정 중에서는 내부 API를 꼼꼼하게 살펴보지는 않았습니다.

UART API가 어떻게 동작하는 지, 이해를 하기 위해 코드를 분석하였습니다.

제가 내린 결론으로는 역시 저보다 훨씬 뛰어난 사람들이 잘 잡아놓은 구조구나 싶었습니다.

(저도 이렇게 좀 짜임새 있게 코드 구현을 하고 싶습니다.)

허나 아쉬운 점은 API를 가지고는 S32K에서 지원하는 다양한 기능을 전부 활용하지 못하는 것으로 보입니다.

지금까지 확인한 바로는 UART에 FIFO를 가지고 있는데.. 설정하는 방법이 없고 IDLE LINE Interrupt에 대한 처리 방법이 없습니다.

직접 구현을 해서 써야하는건지.. 아쉬운 부분입니다.

S32K가 별로 안팔려서 그런걸까요? 뭔가 절반만 구현된 듯한 NXP SDK의 지원이 상당히 아쉽습니다.

다음에는 RX 처리 방식에 대해 알아보겠습니다.

1. 들어가면서

지난 포스팅에 이어서 Timer를 이용한 LED Blinking 실 구현 부분에 대해 이야기하고자 합니다.

S32K는 Reference Manual에서는 Timer Module로 PDB, FTM, LPIT, LPTMR, RTC 총 5개를 정의하고 있습니다.

NXP에서 제공하는 예제 기준으로 LPIT를 활용하였기에, LPIT를 기반으로 한 LED Blinking에 대해 알아보겠습니다.

(실제 구현 코드는 아래에서 다운로드하시면 됩니다.)

2. 시작합니다.

LED를 동작시키기 위한 IO 설정은 이미 다룬 내용이라, 별도의 설명은 하지 않겠습니다.

(그림이 잘 안보여서.. 다시 올릴 예정입니다.)
hy-park.tistory.com/6?category=891221

1. Processor Expert 활성화
아래와 같은 화면을 만나게 됩니다.

(개인적으로 해당 구성도 정말 마음에 들지 않습니다.. 뭔가 정리가 안된듯한 느낌의 구조입니다. 

Peripheral Abastraction Layer와 Peripheral Drivers의 차이는 뭐지?라는 생각이 들었습니다. 그리고 왜 Analog는 별도로 분리 해두었는지 이해가 안 되었습니다. 마치.. 해당 환경 개발에 컨트롤 타워가 없다는 생각이 들 정도입니다.)

Peripheral Driver는 ST의 Low Level Driver와 유사하다고 생각하면 됩니다.

Device의 의존성을 가지고 있어, 해당 API로 개발을 하면 이식성이 떨어지게 되지만.. 보다 Light 하게 개발이 가능합니다.

Peripheral Abstraction Layer는 ST의 HAL과 비슷하여, Peripheral Driver를 한 단계 더 추상화하여 이식성을 높였다고 생각하면 됩니다. 대신 무거워지는 건 덤입니다.

(참고 : community.nxp.com/t5/S32-SDK/S32K144-Driver-vs-PAL/m-p/1019121)

2. Peripheral Abstraction Layer의 timing_pal 추가

timing_pal을 더블 클릭하면, 좌측 하단에 Components가 생성됩니다.

3. LPIT 공급 Clock 설정

좌측 하단에 clockMan1을 더블 클릭하여, Clock 설정 창을 켭니다.

LPIT는 아래 그림처럼 SOSCDIV2_CLK, SIRCDIV2_CLK, FIRCDIV2_CLK, SPLLDIV2_CLK 중 한 개를 공급 Clock으로 사용할 수 있습니다.

저의 경우 1초 Blinking을 만들기 위해, 주파수가 낮은 Clock이 필요하여 SIRCDIV2_CLK를 선택하였습니다.

또한, SIRCDIV2_CLK는 기본 클럭이 8 MHz이므로, Functional Clocks의 SIRCDIV2_CLK의 분주를 조정하였습니다.

(나머지 Clock 설정은 Default 상태 유지)

4. LPIT 설정

timing_pal1을 더블 클릭하여, timing_pal 설정 창을 켭니다.

Device의 Drop box 부분을 LPIT0로 변경합니다.

앞에서 LPIT Clock을 1 Mhz로 설정하였기에, 1 Tick은 1us라고 친절하게 설명해주고 있습니다.

5. Code Generate

5. 코드 구현

LPIT Timer를 구동하기 위해, 아래의 3가지 API를 사용해야 합니다.

• TIMING_Init
  -> 위에서 설정한 LPIT의 실질적인 초기화 수행
  

• TIMING_StartChannel
  -> Timer 동작의 주기 설정
  (위에서 설정한 Tick이 1us이기 때문에, 1초 동작을 위해서는 1,000,000 Tick 이후 Interrupt가 발생해야 함)

• TIMING_InstallCallback
  -> Interrupt 발생 시, 호출될 Callback 등록

main문에는 다음과 같이 작성하였습니다.

너무 간단한 내용이라, 별도 설명을 추가하지 않도록 하겠습니다.

TIMING_InstallCallback에 등록한 Callback 함수의 구현체는 다음과 같습니다.

6. 동작

3. 나갑니다.

다음 포스팅에서는 실제 Register 값과 Call Stack을 보면서 어떤 식으로 Interrupt가 처리되는지 알아보겠습니다.

1. 들어가면서

현업의 바쁨과 담당하고자 한 S32K 기반 프로젝트가 취소되고
S32K가 널리 쓰이지 않는 MCU다보니.. 방문자도 거의 없어 포스팅을 중단했지만..
그래도 댓글을 남겨주신 분이 있어 정보를 나누고 싶어 다시 포스팅을 시작하게 되었습니다.

이번 포스팅은 TIMER를 활용하여, LED를 깜빡이는 방법을 이야기하고자 합니다.

TIMER를 사용하다 보니, Clock 설정이 전부라서.. Clock 설정에 대한 부분을 이번 포스팅에서 이야기하고,

나머지 실 구현 부분은 다음 포스팅에서 다루겠습니다.

2. 시작합니다.

S32K Reference Manual(이하 RM)의 27.4 Internal clocking requirements를 살펴보겠습니다.

S32K는 다양한 Clock Run Mode를 가지고 있습니다.

Manual에서 아래와 같이 4가지의 모드로 구분하고 있습니다.

(개인적인 Clock모드를 구분해서 사용한 적이 없어 조금은 생소한 부분이었습니다.)

1. Slow RUN

2. Normal RUN

3. High Speed RUN (HSRUN)

4. Very Low Power RUN (VLP RUN)

아래는 RM에서 언급하고 있는, 모드 별 최대 Clock과 예제에서 사용하는 Clock 설정입니다.

Slow Run이 빠져있는데 RUN 모드와 차이가 없어.. 빼놓은 것으로 추정해봅니다.

각 모드별 특징적인 부분에 살펴보면 

• CORE_CLK과 SYS_CLK은 HSRUN Mode에서는 112 MHz 이하, Normal Run Mode에서는 80 MHz로 이하로 설정해야 합니다.
  (BUS_CLK 보다 작아서 안됩니다.)

• BUS_CLK은 HSRUN Mode에서는 56 MHz 이하, RUN 모드에서는 48 MHz 이하로 설정해야 합니다.

  (만약 System Clock을 PLL로 사용하면, BUS_CLK는 40 MHz로 제한됩니다. - 아래 그림 참조)

• FLASH_CLK는 HSRUN Mode에서는 28 MHz 이하, RUN 모드에서는 26.67 MHz 이하로 설정해야 합니다.

Processor Expert를 통해, Clock 설정에 대해 조금 더 자세히 다뤄보겠습니다.

아래 그림 화살표에 표기된 것처럼, 크게 4가지 Category를 설정해야 합니다.

• Peripheral Clocks

• Functional Clocks

• Interface Clocks

• Closck Sources

(개인적인 생각에.. UI가 참 아쉽습니다.
가장 먼저 설정해야 하는 Clock Sources가 가장 밑에 있고, 가장 나중에 설정하게 될 Peripheral Clocks가 맨 위에 있습니다......)

원래 내용으로 돌아와서

Clock Sources부터 보겠습니다.

S32K MCU의 주요 근본 Clock에 대해 설정하는 부분입니다. 

SIRC_CLK는 내부적으로 8 MHz를 생성, FIRC_CLK는 내부적으로 48 MHz를 생성해줍니다. 

SOSC_CLK는 외부에 Crystal 등이 장착되었을 때, 설정하게 됩니다.

이후 해당 SOSC를 통해 생성된 Clock을 기반으로, SPLL_CLK을 설정하여 다양한 값의 Clock을 만들 수 있습니다.

다음은 Interface Clocks입니다.

RM에서 언급한 것과 다르게 3가지의 모드로 구분을 하고 있는 것을 볼 수 있습니다.

(RUN, VLPR, HSRUN)

기본 설정에서 볼 수 있듯, RUN은 FIRC_CLK,  VLPR은 SIRC_CLK, HSRUM은 SPLL_CLK을 사용하고 있습니다.

아래 그림과 같이 Source Clock을 변경이 가능한데, 48 MHz 이상의 Clock을 사용하기 위해서는 SPLL_CLK을 사용해야만 합니다. (만약 SPLL_CLK을 사용하게 된다면 BUS_CLK은 40 MHz 이하로 설정을 해야 합니다.)

(여기서도 개인적으로 아쉬운 부분인데.. Cortex-M4 Core를 사용하지만.. RUN 모드에서 최대 80 MHz 밖에 되지 않는 것이... Automotive는 아니지만, 기본 100 MHz가 넘어가는 ST에 비하면 많이 아쉽습니다.)

(HSRUN 모드를 쓰면 되지 않나?라는 의견이 있을 수 있습니다만.. HSRUN 모드에서는 제약이 있습니다. 

우선 온도 조건이 Automotive를 충족하지 못하고, 사용 불가한 기능들이 있습니다.)

SCS_CLK은 System에서 어떤 Clock(SOSC, SIRC, FIRC, SPLL)을 사용할지 결정하는 부분입니다.

Clock Diagram 상 아래 그림의 표시된 부분에 해당합니다.

SYS_CLK은 CORE_CLK입니다. 만약 RUN 모드에서 80 MHz 이상을 설정하게 되면 아래와 같은 오류 메시지가 발생합니다.

BUS_CLK 또한 마찬가지로 RUN 모드에서는 40 MHz 이상 설정이 불가능합니다.

SLOW_CLK은 FLASH_CLK입니다.

다음은 Functional Clocks입니다.

해당 Clock들은 peripheral들이 사용하는 Clock이 됩니다.

자세한 부분은 Pheripheral 설정을 하면서 다뤄볼 예정입니다.

아래 그림처럼 각 CLK이 고정 값을 가지는 것은 아니고 분주를 통해 다양한 값을 만들 수 있다는 점이 매우 좋은 부분입니다.

마지막은 Peripheral Clocks입니다.

이 부분은 각 Peripheral 별로 설정이 필요하기에, 각각의 포스팅에서 다뤄보겠습니다.

3. 나갑니다.

다음 포스팅에서는 실질적인 LPIT와 Clock 설정을 통한 LED 동작 방법에 대해 알아보겠습니다.