[RTOS 개발] 리펙토링을 통해 프로젝트의 기본적이 구조 구성 완료

- 프로젝트 Github

https://github.com/MainForm/BaremetalOS

GitHub - MainForm/BaremetalOS

---

1. 지금까지 진행상황

  드디어 프로젝트의 리펙토링이 끝났습니다. 아직 부족한 부분도 많지만 다음 기능을 추가할 정도로 코드가 정리가 되었습니다. 코드를 정리하면서 몇가지 고민한 부분도 있지만 적절히 판단하여 해결하였습니다. 이번 리펙토링을 통해 얻은 결과는 다음과 같습니다.

1.1. HAL(Hardware Abstraction Layer) 추가

  리펙토링을 하는 가장 큰 이유가 HAL추가 입니다. HAL를 추가함으로써 OS가 하드웨어에 대한 의존도를 낮추고 하드웨어를 접근하는 방법을 단일화하여 OS 개발시 하드웨어에 대한 고민을 줄일 수 있습니다. 반대로 하드웨어도 OS에 대해 독립적이므로 새로운 하드웨어를 추가하는데 큰 어려움이 없습니다.  하지만 HAL을 추가하는 것은 쉬운일이 아니였습니다. 2가지 가장 큰 난관이 있었습니다. 첫번째는 프로젝트 파일 구조에 대한 문제점입니다. 두번째는 선택적 프로젝트 빌드 과정입니다. 이외에도 더 다양한 난관이 있었지만 결국 가장 큰 난관은 2개로 좁혀집니다.

1.1.1. 프로젝트 파일 구조 구성

  먼저 첫번째 난관인 프로젝트 파일 구조는 리펙토링을 하는데 있어서 프로젝트의 기반을 세우는 일과 같습니다. 앞으로 새로운 소스코드를 추가할 때 명확한 위치에 추가하여야 프로젝트 크기가 커지더라도 가독성이 증가하고 원하는 파일을 찾기 쉬워집니다. 또한 빌드를 자동화를 하는데 있어 프로젝트의 파일구조도 매우 중요합니다. 그렇기에 프로젝트의 파일 구조를 결정하는데 꽤나 많은 시간을 소비하였습니다. 결국, "peripheral", "BaremetalOS", "HAL"의 3개 커다란 구조를 설정하고 각 구조에 대한 세밀한 구조를 설정하였습니다. 여기서 가장 중요한 것은 "HAL" 구조 였습니다. "HAL"은 "peripheral"과 "BaremetlOS"을 이어주는 역할 및 개발 보드에서 필요한 "peripheral"의 구조를 구성하는 역할을 담당하게 하였습니다.

 

1.1.2. Peripheral에 따른 선택적 빌드 자동화

  두번째 난관은 개발 보드에 따라 Peripheral를 선택적으로 빌드하는 과정을 자동화는 것입니다. 현재 빌드 과정을 자동화하는 프로그램으로 make를 사용하고 있습니다. 하지만 지금까지 make를 사용하면서 필요에 따라 소스코드를 선택적으로 빌드하는 방법은 이전에 해보지 않은 방법이였습니다. 또한 제가 원하는 방법은 하나의 타겟보드를 설정하면 그에 해당하는 peripheral이 자동적으로 선택되어 자동적으로 빌드하는 방법을 원했습니다. 이러한 빌드 방법을 해결하기 위해서 선택한 방식은 각 보드별로 "board.mk"파일을 만들어 보드별 필요한 peripheral를 변수로 미리 선언하고 "Makefile"에서 해당 "board.mk"를 include하여 원하는 peripheral를 선택적으로 빌드하는 방법을 고안하였습니다.

대략적으로 구성한 BaremetalOS 구조

2. 앞으로 진행 예정

  이제 리펙토링을 마치고 새로운 기능을 추가할 때가 왔습니다. 가장 먼저 추가할 기능은 Qemu 에뮬레이터를 통해 임시로 펌웨어를 실행시켜 보는 것입니다. 물론 실제 하드웨어와는 많은 차이가 존재하지만 실제 보드에 펌웨어를 실행시키기 전 테스트로는 충분히 만족스러운 성능을 보일 것입니다. 그 다음 Timer Peripheral을 추가할 예정입니다. Timer를 추가함으로써 Linux 커널의 jiffes를 구현할 수 있을 것입니다.

2.1. Qemu 에뮬레이터를 통한 펌웨어 실행

  펌웨어를 실제 하드웨어에 매번 실행하는 것은 앞으로 매우 힘들어 질 것입니다. 특히 JTAG와 같은 디버깅 툴도 없어 단순히 UART로 디버깅하는 현재 상황에서는 문제가 발생할 때 상태 레티스터를 확인하에 어려움이 있습니다. 하지만 에뮬레이터를 사용한다면 GDB를 사용하여 레지스터를 확인하기 쉬워집니다. 물론 에뮬레이터이므로 실제 하드웨어와 큰 차이가 있지만 하드웨어 문제가 아닌이상대략적인 문제점은 같을 것입니다.

  그리고 펌웨어의 기능을 확인 하기 위해 일일이 실제 하드웨어에서 실행하는 것은 시간적인 손실이 너무 큽니다. 그렇기에 하드웨어와 관련한 테스트가 아닌 이상 굳이 하드웨어를 일일이 실행하는 것은 번거로운 작업입니다. 

2.2. Timer peripheral 추가

  Timer를 추가하여 앞으로 OS 개발에 있어서 Jiffes의 구현 및 스케쥴링 이벤트 발생 등 다양한 OS 기능을 추가할 것입니다. 또한 비교적 정확한 시간을 셀 수 있으므로 RTOS에 있어서 매우 중요한 부분이라고 할 수 있습니다.

3. 후기

  사실 지금까지 코드를 작성하면서 리펙토링을 잘 하지 않아 리펙토링하는데에 꽤나 난관을 격었습니다. 하지만 리펙토링 후 기능을 더 추가하기 쉬워지게된 지금 리펙토링이 프로젝트 관리에 있어서 얼마나 중요한지를 알게되었습니다. 그리고 이제 OS개발에 있어서 삽을 하나 뜬 것같은 기분이 듭니다.