Embedded Toolchains
임베디드 툴체인
While mbed qualifies as a viable embedded development platform with a clear path from prototype through to production, any vendor vendor neutral high-level API or platform necessarily requires some loss of control over the low-level implementation details.
mded는 프로토타입부터 생산까지 명확한 경로를 갖춘 실행 가능한 임베디드 개발 플랫폼으로 적합하지만, 공급업체 중립적인 상위 수준 API 또는 플랫폼은 필연적으로 하위 수준 구현 세부 사항에 대한 통제력을 어느 정도 상실해야 합니다.
You generally trade ease of use for certain low-level optimizations in the code and drivers.
일반적으로 코드 및 드라이버의 특정 하위 수준 최적화를 위해 사용 편의성을 교환합니다.
This tradeoff makes sense in many situations, but obviously there is no one-size-fits-all approach with embedded development.
이러한 절충안은 많은 상황에서 타당하지만 임베디드 개발에는 모든 경우에 적용되는 단일한 접근 방식은 없습니다.
In the product design world, performance and control often trump ease of use, and many engineers still prefer to handle all of the implementation details themselves, writing their own low-level drivers and setting up their own build environment.
제품 디자인 세계에서는 성능과 제어가 사용 편의성보다 우선시되는 경우가 많으며, 많은 엔지니어는 여전히 모든 구현 세부 사항을 직접 처리하고 자체 하위 수준 드라이버를 작성하고 자체 빌드 환경을 설정하는 것을 선호합니다.
Writing your own low-level drivers clearly requires more development effort, but it also ensures you have maximum control over the code running your products.
자신만의 하위 수준 드라이버를 작성하려면 더 많은 개발 노력이 필요하지만 제품을 실행하는 코드를 최대한 제어할 수 있습니다.
It also forces you to understand the processor more intimately and allows you to optimize for performance and cost to a far greater extent.
또한 프로세서를 더 자세히 이해할 수 있게 해주고 성능과 비용을 훨씬 더 많이 최적화할 수 있게 해줍니다.
Being able to fully optimize the code for size and performance is extremely important with embedded products.
임베디드 제품에서는 크기와 성능에 맞게 코드를 완전히 최적화할 수 있는 것이 매우 중요합니다.
Optimizing for code size, for example, might allow you to use a smaller and cheaper processor, shaving $2 or $3 off the bill of materials, which can easily translate into $5 to $10 or more on the retail price.
예를 들어 코드 크기를 최적화하면 더 작고 저렴한 프로세서를 사용할 수 있어 BOM (Bill of Material/자재표)에서 2~3달러를 절약할 수 있으며 이는 소매 가격으로 쉽게 환산하면 5~10달러 이상으로 환산될 수 있습니다.
That savings can make all the difference between a product that succeeds or something that fails because it ends up in the wrong price bracket.
이러한 비용 절감으로 인해 제품이 성공할지, 아니면 잘못된 가격대에 속해 실패할지 사이에 큰 차이가 생길 수 있습니다.
The best way to control the final code size and performance is to have full control over your compiler and your build environment, allowing you to make the most out of every clock cycle on your embedded processor or SoC.
최종 코드 크기와 성능을 제어하는 가장 좋은 방법은 컴파일러와 빌드 환경을 완전히 제어하여 임베디드 프로세서 또는 SoC의 모든 클록 주기를 최대한 활용할 수 있도록 하는 것입니다.
Compiling code for small embedded processors requires something called a toolchain.
소형 임베디드 프로세서용 코드를 컴파일하려면 툴체인이라는 것이 필요합니다.
As the name implies, a toolchain is a collection of tools used to build executable code, and one of the most important parts of this toolchain is the cross-compiler.
이름에서 알 수 있듯이 툴체인은 실행 가능한 코드를 작성하는 데 사용되는 도구 모음이며 이 툴체인의 가장 중요한 부분 중 하나는 크로스 컴파일러입니다.
The cross compiler compiles code while running on one architecture (for example, using an x86 instruction set) but produces code for a different architecture (for example, some variant of ARM).
크로스 컴파일러는 하나의 아키텍처에서 실행되는 동안 (예: x86 명령어 세트 사용) 코드를 컴파일하지만 다른 아키텍처 (예: 일부 ARM 변형)에 대한 코드를 생성합니다.
You have a number of commercial and open source options for cross compilers and low-level embedded toolchains, both commercial and open source, but we’ll focus on an open source solution in this section.
상용 소스와 오픈 소스 모두 크로스 컴파일러와 저수준 임베디드 툴체인을 위한 다양한 상용 및 오픈 소스 옵션이 있지만 이 섹션에서는 오픈 소스 솔루션에 중점을 둘 것입니다.
In recent years, GCC (the free, open source compiler collection that’s part of the GNU project) has made significant leaps and bounds in its support for ARM.
최근 몇 년 동안 GCC (GNU 프로젝트의 일부인 무료 오픈 소스 컴파일러 컬렉션)는 ARM에 대한 지원 측면에서 상당한 진전을 이루었습니다.
Most of these advances are related to the dominance of ARM in the mobile phone and tablet arena (typically using ARM Cortex-A processors), but small, deeply embedded processors (ARM Cortex-M, etc.) have also benefited from the huge investments made here, due to overlapping instruction sets.
이러한 발전의 대부분은 모바일 폰과 태블릿 분야에서 ARM이 우위를 점한 데 따른 것입니다 (일반적으로 ARM Cortex-A 프로세서 사용). 하지만 작고 내장형 프로세서(ARM Cortex-M 등)도 명령어 세트가 중복되기 때문에 여기에서 이루어진 막대한 투자의 혜택을 입었습니다.
Widely used in a variety of industries, GCC is also conveniently available on any modern operating system and architecture.
다양한 산업 분야에서 널리 사용되는 GCC는 모든 최신 운영 체제 및 아키텍처에서도 편리하게 사용할 수 있습니다.
Code targeting GCC is generally highly portable, and you can build the same output on Linux, OS X, Windows, or almost any other environment you can imagine with no meaningful variation in the compiler output.
GCC를 대상으로 하는 코드는 일반적으로 이식성이 뛰어나며 Linux, OS X, Windows 또는 컴파일러 출력에 의미 있는 변화 없이 상상할 수 있는 거의 모든 기타 환경에서 동일한 출력을 빌드할 수 있습니다.
The latter point is extremely important and one of the main factors that makes GCC an excellent choice for embedded development.
후자의 포인트는 매우 중요하며 GCC를 임베디드 개발을 위한 탁월한 선택으로 만드는 주요 요인 중 하나입니다.
GCC does an excellent job with ARM Embedded Toolchains processors today, but some commercial compilers still perform better at certain tasks.
GCC는 오늘날 ARM Embedded Toolchains 프로세서에서 탁월한 성능을 발휘하지만 일부 상용 컴파일러는 여전히 특정 작업에서 더 나은 성능을 발휘합니다.
What GCC offers that no commercial toolchains can, though, is the assurance that you will always be able to rebuild your firmware using the same compiler version and dependencies.
그러나 어떤 상용 툴체인도 제공할 수 없는 GCC가 제공하는 것은 동일한 컴파일러 버전과 종속성을 사용하여 항상 펌웨어를 다시 빌드할 수 있다는 보장입니다.
If commercial toolchains that require activation (and thus activation servers) aren’t kept up to date, they might not be able to guarantee that they’ll run on the current generation of operating systems or PCs.
활성화가 필요한 상용 도구 체인 (및 활성화 서버)이 최신 상태로 유지되지 않으면 현재 세대의 운영 체제 또는 PC에서 실행된다는 보장이 없을 수도 있습니다.
If you’re new to embedded development, it’s easy to overlook this detail.
임베디드 개발이 처음이라면 이 세부 사항을 간과하기 쉽습니다.
Embedded devices can have lifespans of 10 or 20 years or more, far beyond the lifespan of most software packages.
임베디드 장치는 대부분의 소프트웨어 패키지 수명보다 훨씬 긴 10년 또는 20년 이상의 수명을 가질 수 있습니다.
Commercial tools and development environments you use today might not exist in 10 years, and the vendor might not be around in the future to activate that long-retired product you invested heavily in years ago.
오늘날 사용하는 상용 도구와 개발 환경은 10년 후에는 존재하지 않을 수도 있고, 수년 전에 많은 투자를 한 그 오래된 제품을 활성화해 주는 공급업체가 미래에 존재하지 않을 수도 있습니다.
GCC offers you the assurance that you’ll never face this problem, since you can archive the full source of your cross-compiler, including any library dependencies, along with your firmware code and know you can rebuild it all at any point in the future.
GCC를 사용하면 라이브러리 종속성을 포함한 크로스 컴파일러의 전체 소스와 펌웨어 코드를 보관하고 언제든지 모든 것을 다시 빌드할 수 있으므로 이런 문제가 발생하지 않을 것이라는 확신을 가질 수 있습니다.
Setting up a GNU toolchain on a non-Linux PC used to be a reasonably involved task, but ARM has made now made it trivial by providing precompiled, regularly updated versions of GCC for Windows, OS X, and Linux, including easy-to-use installers that take care of many of the messy details.
Linux가 아닌 PC에 GNU 툴체인을 설정하는 것은 예전에는 상당히 복잡한 작업이었지만, ARM에서는 Windows, OS X, Linux용 GCC의 사전 컴파일되고 정기적으로 업데이트되는 버전을 제공함으로써 이를 손쉽게 만들었습니다. 여기에는 많은 복잡한 세부 사항을 처리하는 사용하기 쉬운 설치 프로그램도 포함됩니다.
The first step in setting up a development environment for ARM is to download the latest prebuilt GNU toolchain.
ARM용 개발 환경을 설정하는 첫 번째 단계는 사전 빌드된 최신 GNU 도구 체인을 다운로드하는 것입니다.
As shown in Figure 10-1, you can download convenient installers for OS X, Windows, and Linux, as well as the raw source code and a guide on building the toolchain yourself on other platforms.
그림 10-1에 표시된 것처럼 OS X, Windows 및 Linux용 편리한 설치 프로그램은 물론 원시 소스 코드와 다른 플랫폼에서 직접 툴체인을 구축하는 방법에 대한 가이드도 다운로드할 수 있습니다.
The latest version available on the website might vary, but you should generally choose the most recent package.
웹사이트에서 사용 가능한 최신 버전은 다를 수 있지만 일반적으로 가장 최신 패키지를 선택해야 합니다.
ARM provides quarterly updates, often incorporating improvements into the compiler and associated libraries, yielding smaller or more efficient compiled code.
ARM은 분기별 업데이트를 제공하며 종종 컴파일러 및 관련 라이브러리에 개선 사항을 통합하여 더 작거나 더 효율적인 컴파일된 코드를 생성합니다.
If you’re using OS X or Linux, you simply need to download the appropriate installer and run it.
OS X 또는 Linux를 사용하는 경우 적절한 설치 프로그램을 다운로드하여 실행하기만 하면 됩니다.
Any other development tools (make, various commands used in the makefile, etc.) are likely already available on your development machine or are easy to add (using Xcode on OS X and your package manager on Linux).
다른 개발 도구 (make, makefile에 사용되는 다양한 명령 등)는 개발 컴퓨터에서 이미 사용 가능하거나 쉽게 추가할 수 있습니다 (OS X에서는 Xcode, Linux에서는 패키지 관리자 사용).
You can use the following command to confirm whether the GCC cross-compiler was successfully installed:
다음 명령을 사용하여 GCC 크로스 컴파일러가 성공적으로 설치되었는지 확인할 수 있습니다:
You should get a response that looks like this:
다음과 같은 응답을 받아야 합니다:
If you see this output, it means that your cross-compiler has been successfully installed and you can generate ARM binaries on your development machine.
이 출력이 표시되면 크로스 컴파일러가 성공적으로 설치되었으며 개발 컴퓨터에서 ARM 바이너리를 생성할 수 있음을 의미합니다.
If you’re using a Windows machine for development, you need to download the appropriate Windows installer and run it in the same manner you would any other installation package.
개발을 위해 Windows 시스템을 사용하는 경우 적절한 Windows 설치 프로그램을 다운로드하고 다른 설치 패키지와 동일한 방식으로 실행해야 합니다.
Make sure to select the post-installation option to “Add path to environment variable” (as shown in Figure 10-2).
설치 후 옵션으로 "환경 변수에 경로 추가"를 선택해야 합니다 (그림 10-2 참조).
This will ensure that the toolchain is accessible from anywhere, which will generally make things easier when working with multiple folders and file locations.
이렇게 하면 어디에서나 툴체인에 액세스할 수 있으므로 일반적으로 여러 폴더와 파일 위치에서 작업할 때 작업이 더 쉬워집니다.
Similar to the OS X/Linux test shown previously, if everything is set up properly, you should be able to drop down to the command line and enter the following command to see which version of the GNU toolchain you’ve installed:
이전에 표시된 OS X/Linux 테스트와 유사하게 모든 것이 제대로 설정되었다면 명령줄로 드롭 다운하여 다음 명령을 입력하여 설치된 GNU 툴체인 버전을 확인할 수 있어야 합니다:
Unlike Linux and OS X, Windows usually won’t have some of the additional command line tools the GNU toolchain generally requires, such as make and a number of *nix commands to work with files and directories (ls, cp, etc.).
Linux 및 OS X와 달리 Windows에는 일반적으로 파일 및 디렉터리 (ls, cp 등) 작업을 위한 make 및 여러 *nix 명령과 같이 GNU 도구 체인에 일반적으로 필요한 일부 추가 명령줄 도구가 없습니다.
Thankfully, installing these additional tools on Windows is easy.
다행히도 이러한 추가 도구를 Windows에 설치하는 것은 쉽습니다.
GNU CoreUtils for Windows adds precompiled versions of all the file-editing commands you’ll need.
Windows용 GNU CoreUtils는 필요한 모든 파일 편집 명령의 사전 컴파일된 버전을 추가합니다.
Download the complete CoreUtils for Windows package, except sources, and run the installer.
소스를 제외한 전체 Windows용 CoreUtils 패키지를 다운로드하고 설치 프로그램을 실행합니다.
You’ll also need make, which you’ll use to control the compilation process and convert your source code into something meaningful that you can run on the nRF51822.
컴파일 프로세스를 제어하고 소스 코드를 nRF51822에서 실행할 수 있는 의미 있는 코드로 변환하는 데 사용할 make도 필요합니다.
After installing GNU Coreutils for Windows, download and install Make for Windows.
Windows용 GNU Coreutils를 설치한 후 Make for Windows/윈도우용으로 만들기를 다운로드하여 설치합니다.
You can test if make was installed successfully by dropping down to the command line and entering the following command, which should give you a version number as a response:
명령줄로 드롭다운하고 다음 명령을 입력하여 make가 성공적으로 설치되었는지 테스트할 수 있습니다. 그러면 응답으로 버전 번호가 제공됩니다:
Once both of these tools have been installed, you should have everything you need to cross-compile code for ARM on your development PC.
이 두 도구가 모두 설치되면 개발 PC에서 ARM용 코드를 크로스 컴파일하는 데 필요한 모든 것이 갖추어져 있어야 합니다.
Now, you can get started with the nRF51822 codebase and a sample project.
이제 nRF51822 코드베이스와 샘플 프로젝트를 시작할 수 있습니다.