개발에 날개를 달아 보세요.
적절한 툴을 적절한 방식으로 사용함으로써, 개발 주시를 단축시키는 것이 가능해집니다. IAR Embedded Workbench는 그 우수한 성능 뿐 아니라, 다양하고 스마트한 기능으로 개발자의 업무를 쉽게 해 주는 것으로 널리 알려져 있는 제품입니다. 그러지만 이 모든 기능을 정말 제대로 사용하고 있는 것일까요? 이번 기사에서는 유용한 팁과 요령을 소개합니다. 7가지 팁을 통해 개발 속도에 날개를 달아 보세요
Make & Restart Debugger 기능 사용하기
디버그를 하는 중에 소스 코드를 수정해야 하는 경우가 있을 수 있습니다. 이미 디버그 세션 중에 바로 코드를 수정할 수도 있다는 사실을 아시는 분도 계실 것입니다. 하지만 이렇게 코드를 바꾸면 바로 반영되지는 않습니다. 코드를 변경한 내용의 효과를 발생시키기 위해서는 디버그 세션을 멈추고, Make를 선택한 다음 Download and Debug를 선택해야 합니다. 이러한 과정의 번거로움을 덜어 드리기 위해 IAR Embedded Workbench에서는 Make & Restart Debugger 버튼을 마련해 두고 있습니다.
이 버튼을 클릭하면 디버그 세션이 멈추고, make 작업을 수행한 다음에 디버그 세션 시퀀스가 다시 시작됩니다. 그러므로 손으로 작업하던 단계를 일부 건너 뛰고, 좀 더 간편하게 시행착오를 계속 겪어 나가실 수가 있을 것입니다.
Download and Debug(다운로드 후 디버그) 또는 Debug without Downloading(다운로딩 없이 디버그) 선택
IAR Embedded Workbench IDE에는 디버그 세션을 시작할 수 있는 두 가지 버튼이 존재합니다.
Download and Debug를 선택하면 C-SPY 디버거가 실행 가능 데이터를 플래시 또는 RAM으로 다운로드 받은 다음에 해당 정보를 C-SPY에 로드합니다. 이미 빌드가 되어 있는 오브젝트의 디버깅 시에는 이 방법이 안전합니다.
Debug without Downloading에서는 대상 기기 메모리로의 다운로드 과정을 생략하고 디버그 정보를 바로 로드합니다. 이 옵션은 실행 데이터 상에 변동이 없는 경우, 디버그 세션을 다시 시작하기 위해 사용합니다. 이를 통해 불필요한 다운로드 절차를 반복하지 않고 건너뛰어 시간을 절약할 수가 있는 것입니다. Debug without Downloading 기능은 빌드 되어 있는 오브젝트 상에 변동 사항이 없는 것이 확실한 경우에만 사용하십시오. 그렇지 않을 시 C-SPY 상의 정보가 부정확해질 수가 있습니다. 예를 들어, 표시되는 소스 코드가 실제와 일치하지 않을 수가 있는 것입니다.
Make 또는 Rebuild All 선택하기
실행 가능 파일, 또는 라이브러리 파일을 생성하려면 Project>Make 또는 Project>Rebuild All을 선택합니다.
Rebuild All의 경우는 이미 컴파일 된 오브젝트를 모두 삭제하고 컴파일과 링크를 모든 파일에 대해 다시 실시합니다. Make는 마지막으로 빌드를 수행한 후 변동이 있었던 파일 만을 컴파일 및 조합, 링크합니다.
헤더 파일을 변경하셨거나, 컴파일러 최적화 설정 등의 빌드 옵션을 사용하시는 경우 항상 Rebuild all을 선택하시는 것이 좋습니다. 하나의 소스 파일 또는 소수의 소스 파일로 작업을 하시는 경우 Make를 대신 사용하시면 빌드 시간을 절약할 수 있습니다. 프로젝트에 사용되는 코드의 양이 많을 수록, 이렇게 절약할 수 있는 시간은 늘어납니다.
Auto Indent(자동 들여쓰기) 사용
C/C++ 언어에서는 들여쓰기를 반드시 할 필요는 없습니다. 들여쓰기 여부와 관계없이, 컴파일러가 생성하는 코드는 동일합니다. 그러나 프로그래머의 입장에서는 들여쓰기를 하는 것이 중요합니다. 코드 블록을 확인하고, 코드 구역 간의 위계 구조를 파악할 수가 있기 때문입니다.
그런데 다른 프로젝트의 코드를 복사 후 붙여 넣으시는 경우, 들여쓰기 방식에 차이가 있습니다. 물론 손으로 하나씩 고치셔도 되지만, 수고를 덜어드릴 수 있는 방법이 있습니다.
수정하고자 하는 코드를 선택한 다음, Edit >Auto Indent를 누르세요.
그러면 선택한 코드에 대해 들여쓰기를 수정해 줍니다:
코드를 재사용하지 않고 직접 써 버리는 것을 선호하시는 경우, 먼저 Auto Indent를 실행한 다음에 코드를 작성하시면 됩니다.
Block Comment 사용하기
프로젝트의 디버깅 시에는 짧은 시험용 코드 블록을 작성하고, 이것을 활성화/비활성화 시켜 가며 작업하시는 경우가 있을 수 있습니다. 코드 블록을 활성화/비 활성화 상태로 전환하는 방식에는 몇 가지가 있습니다. 예를 들어 #if #endif 지시어를 사용하거나 /* */ 형태의 주석을 달면 됩니다. 그렇지만 #if 지시어는 코드의 가독성을 떨어뜨리고, /* */ 주석은 내재 사용(nested usage)이 어렵습니다. 이를 해결하는 방법은 // 형식의 주석을 대신 사용하는 것입니다. 그리고 Block comment를 사용하시는 경우, 각각의 행에 //를 일일이 달아 주어야 할 필요가 없습니다.
원하는 코드 블록을 선택하고 Edit > Block Comment를 선택하십시오.
뿐만 아니라 이미 주석으로 되어 있는 코드 블록의 경우 Block Uncomment를 사용할 수도 있습니다. 이렇게 코드를 자유롭게 활성화/비활성화 할 수 있게 되면 디버그 작업이 한결 수월해 집니다.
단축키 사용하기
다른 대부분의 소프트웨어와 마찬가지로, IAR Embedded Workbench IDE에도 유용한 단축키가 많이 있으며 이를 통해 개발 효율을 향상시킬 수가 있습니다. 물론 복사하기[Ctrl+C] 와 붙여넣기[Ctrl+V]와 같은 일반적인 단축키도 존재합니다. 또 프로그램 전용의 단축키도 존재합니다. 예를 들어 [F7]은 Make이며, [Ctrl+D]는 Download and Debug로 바로 이어집니다. 이렇게 유용한 단축키는 메뉴 화면을 보시면 찾으실 수 있습니다.
자주 사용하시는 명령어를 선택한 다음, 우측에 나타나는 단축키를 기억해 두십시오.
그리고 아직은 잘 모르시는 분을 위해, 두 가지 아주 유용한 단축키를 알려 드리고자 합니다. 예를 들어, GPIOInit()와 같은 함수의 정의를 보고 싶으시면, 커서로 함수를 선택한 다음 [F12]를 누르십시오.
그러면 해당 함수의 정의로 바로 이동합니다. [F12]키는 Edit>Navigate>Go to Definition에 연결되어 있습니다.
또 다른 유용한 단축키로 [Alt+Left]을 들 수 있습니다. 이 키를 사용하시면 소스 코드 상에서 이전에 있던 위치로 이동합니다. 사실 이것은 다른 여러 인터넷 브라우저에서 사용하고 있는, 이전 페이지 보기 단축키와 동일합니다.
IAR Embedded Workbench IDE의 전체 단축키는 Tools>Options>Key Bindings에서 확인이 가능합니다.
이 화면에서는 단축키의 목록을 조회할 수 있을 뿐 아니라, 자신이 원하는 키와 명령어를 연결시켜 단축키를 원하는 대로 편집할 수가 있습니다.
패러렐 빌드 활성화
이번에 새롭게 소개된 Parallel build 기능은 빌드 소요 시간을 줄여 줍니다. 그리고 현재는 IAR Embedded Workbench 툴의 일부로서 다양한 대상에 이용되고 있습니다. 오늘날 윈도우즈 계열 PC 들은 대부분 멀티코어 CPU를 장비하고 있습니다. 패러렐 빌드는 이러한 프로세스를 빌드 프로세스에 효과적으로 사용할 수 있도록 해 줍니다. Parallel build 기능을 활성화시키려면 Tools>Options으로 들어가십시오.
이어서 Project category를 선택한 다음, Enable parallel build를 선택하시면 됩니다.
Processes에는 컴퓨터 상에서 사용할 수 있는 코어의 개수를 입력합니다. 아래의 그래프는 예시 어플리케이션의 실제 빌드 소요 시간을 비교한 것입니다:
본 예시에서 사용하고 있는 컴퓨터에는 4 개의 코어가 장착되어 있습니다. 여기서는 4개의 프로세스를 동시에 가동하므로, 단일 프로세스를 사용하는 경우에 비해 시간이 두 배로 빨라 지는 것을 보실 수 있습니다. 여기서는 4개의 프로세스와 8 개의 프로세스 간에는 빌드 소요 시간에 차이가 없습니다. 왜냐하면 실제로 존재하는 코어는 4 개 밖에 없기 때문입니다.
만일 사용하시는 IAR Embedded Workbench 버전에서 Parallel build를 지원하는 경우, 항상 해당 기능을 활성화시켜 두실 것을 권합니다. 빌드 타임이 줄어들면 하루에 그 만큼 어플리케이션을 빌드하고 테스트해 볼 수 있는 횟수가 늘어나기 때문입니다.