소프트웨어 개발 툴에 대한 내용은 여기까지이므로 타깃 시스템에 대한 내용을 다룬 후 전체적인 요약정리를 하도록 하겠습니다. 한눈에 내용을 파악하고 싶다면 가장 아래부터 확인하고 각 세부사항은 참고된 링크를 살펴봐주세요.
로케이터는 타깃 소프트웨어의 이미지를 담고 있는 파일을 생성합니다. 이제 그런 파일을 타깃 시스템에 올리는 문제로 주제를 바꿔봅시다. 이렇게 하는 데는 몇 가지의 방법이 있으니 다뤄볼게요.
[PROM 프로그래머 통하기]
로케이터의 출력 파일을 타깃 시스템에 올리는 정통적인 방법은 파일을 이용해서 ROM이나 PROM을 만드는 것입니다. ROM에 맞도록 제작하는 비용이 상당히 높은 편이라서 소프트웨어 개발이 완전히 끝났을 때가 롬을 제작하기 가장 적절한 시점이라고 할 수 있습니다.
프로그램을 PROM 프로그래머라는 장치를 통해서 PROM에다가 넣을 수도 있는데 생산량이 ROM을 사용할 만큼 많지 않고 소프트웨어를 변경할 계획이 있거나 또는 디버깅하는 중이라면 이 방법이 가장 적절합니다. 디버깅을 위해서 PROM과 PROM프로그래머를 사용할 계획이 있다면 회로에 PROM을 직접 납땜하는 것보다는 타깃 시스템에 소켓을 사용해서 PROM을 결합시키는 것이 훨씬 유용하다고 말씀드릴게요.
그렇다면, 버그를 발견할 때마다 타깃 시스템에서 버그가 있는 소프트웨어를 담고 있는 PROM을 제거하고 지울 수 있는 경우에는 ROM 이레이저에 넣거나 지울 수 없을 때는 쓰레기통에 버리고 버그를 잡은 새로운 소프트웨어로 PROM을 프로그램해서 소켓에 PROM을 꼽으면 됩니다. 소켓으로부터 PROM을 제거하기 위해서 칩 제거기 같은 조그만 툴이 필요할 수도 있어요. 칩 제거기는 비싸서 못 사는 물건이 아니고 사용하기도 쉽습니다. PROM을 소켓에 넣을 때는 엄지 손가락만 있으면 됩니다.
만약 PROM 프로그래머를 사용할 예정이라면, 구입할 PROM 프로그래머가 로케이터가 생성한 출력 파일을 이해할 수 있는지 아닌지 프로그래머의 역량에 달려있다고 봐야 합니다. 보통 PROM 프로그래머와 로케이터는 서로 다른 제조사로부터 구입을 할 것이고, 그러므로 다양한 상황이 벌어질 수 있으니 서로 호환성이 있는지를 확인하는 건 전적으로 프로그래머의 책임으로 보입니다.
[ROM 에뮬레이터]
디버깅을 할 목적으로 소프트웨어를 타깃 시스템에다가 넣는 또 다른 방법은 타깃 시스템을 롬을 대체하는 장치로 알고 있는 롬 에뮬레이터를 사용하는 겁니다. 하드웨어의 다른 장치들의 시각에서는 에뮬레이터가 그냥 롬이랑 같겠지만 롬 에뮬레이터는 전자회로의 큰 박스와, 호스트와 연결하기 위한 시리얼 포트 또는 네트워크 연결로 구성되어 있습니다. 호스트에서 돌아가는 소프트웨어는 로케이터에서 생성된 파일을 롬 에뮬레이터에 보낼 수 있고, 그리고 나면 롬 에뮬레이터는 작성한 프로그램을 담고 있는 롬처럼 행동합니다.
PROM 프로그래머와 같이 프로그래머는 코드를 ROM 에뮬레이터에 다운로드하는 소프트웨어가 로케이터가 생성한 파일 형식을 이해할 수 있는지 확인해야 합니다.
[인 서킷 에뮬레이터]
인 서킷 에뮬레이터는 또 다음 파트에서 다룰 예정입니다. 만약에 소프트웨어를 디버깅하기 위해서 인 서킷 에뮬레이터를 사용하고 있는 경우라면, 디버깅을 위해 소프트웨어를 타깃에 넣을 수 있는 방법으로 인 서킷 에뮬레이터의 일반적인 형태인 오버레이 메모리를 사용할 수 있습니다. 자세한 건 다음에 언급이 될 것 같습니다.
[플래시]
만약 타깃이 프로그램을 플래시 메모리에 가지고 있는 상황이라면, 항상 채택할 수 있는 방법은 플래시를 소켓에 넣어서 PROM처럼 다루는 겁니다. 대부분의 PROM 프로그래머는 플래시 메모리를 프로그램할 수 있긴 하지만 타깃이 시리얼 포트, 네트워크 연결 아니면 또 다른 바깥세상과 통신할 수 있는 수단을 가지고 있다고 한다면, 플래시 메모리는 다른 방법이 가능하도록 해줍니다. 프로그래머는 호스트로부터 통신 연결을 통해 플래시에 프로그램을 쓸 수 있도록 하는 작디작은 소프트웨어를 작성할 수 있거든요. 비록 이런 소프트웨어를 작성하는 일이 골치 아파 보이긴 할 테지만 실제로는 더 골치 아플지도 모릅니다. 그렇다고 하더라도 다음과 같은 이유로 작성해야 할 필요가 있습니다.
- 프로그래머는 칩을 소켓으로부터 뽑고 다시 꼽을 때 생길 수 있는 칩의 다리가 휘거나, 선이 끊어지거나, 다른 망가지기 쉬운 프로토타입 하드웨어에 영향을 줄 수 있는 위험이 없이 디버깅을 위해서 새로운 소프트웨어를 시스템에 다운로드할 수 있음.
- 새로운 소프트웨어를 시리얼 포트나 네트워크 연결을 통해 다운로드하는 것은 칩을 소켓에서 뽑아서, PROM 프로그래머로 프로그램을 하고, 다시 소켓이 꼽는 것보다 훨씬 빠름.
- 고객이 새로운 버전의 소프트웨어를 제품에 다운로드하도록 하고 싶은 경우, 어떻게 하든지 이 소프트웨어를 작성해야만 함. 이건 플래시 메모리를 시스템에 넣는 일반적인 이유라고 할 수 있음.
따라서 꼭 작성해야 하지만, 이번 프로젝트를 이것에 사용하기로 마음먹었다면 이제 언급할 문제들에 부딪칠 가능성이 있다는 것도 명심해야 합니다.
- 플래시를 프로그래밍하는 도중에는 플래시로부터 명령어를 읽을 수 없기 때문에 플래시 프로그래밍 소프트웨어는 반드시 자기 자신을 RAM으로부터 복사해야 함. 이것은 소프트웨어가 돌아가는 주소를 모두 변경시킬 것임. 로케이터는 원래의 위치인 플래시에서 돌아가는 소프트웨어를 생성할 것이기 때문에, 프로그래머는 새로운 위치에서 어떻게 동작하게 할지를 알아내야 함.
- 아마도 먼저 다운로드하던 도중에 시스템이 다운되었더라도, 타깃 시스템이 새로운 소프트웨어를 다운로드하기를 원할 것임. 이렇게 하기 위해서, 플래시 프로그래밍 소프트웨어가 시스템에서 작동하는 유일한 소프트웨어라고 할지라도, 시스템이 실행시킬 수 있는 견고한 방법을 마련해야 함.
- 같은 이유에서 플래시 프로그래밍 소프트웨어 자체를 수정할 때마다 그것을 RAM에다가 다운로드하고 플래시에 올리길 원할 것임. 이것을 가능하게 하기 위해서는 플래시 프로그래밍 소프트웨어가 플래시 안의 한 주소 영역에 모두 있다는 것과 다른 블록이나 라이브러리 함수들에 의존하지 않는다는 것을 확실히 해야 함. 종종, 프로그래머는 플래시 프로그래밍 소프트웨어를 하나의 세그먼트에 따로 넣어서, 로케이터가 다른 코드와는 별도의 영역에 올라가도록 해야 할 필요가 있음.
- 플래시 프로그래밍 소프트웨어를 디버깅할 때는 이 소프트웨어를 타깃에 올리기 위해서 다른 방법들 중의 하나를 사용해야만 함.
[모니터 프로그램]
통신 포트를 가지고 있는 시스템이라면, 타깃의 롬에 있으면서 새로운 프로그램을 시스템에 다운로드하는 방법을 알고 있는 모니터 프로그램이라고 불리는 수단을 선택할 수 있습니다. 일반적인 모니터 프로그램은 소프트웨어를 시리얼 포트를 통해서 보내고, 타깃의 램에다가 그 소프트웨어를 저장하고, 실행하게 해 줍니다. 가끔씩 모니터 프로그램은 로케이터의 기능을 대신해서 수행하기도 하고, 브레이크 포인트를 설정하거나 메모리 또는 레지스터의 값을 보여주는 디버깅 서비스를 제공하기도 합니다. 스스로의 모니터 프로그램을 작성할 수도 있지만, 많은 RTOS 제조 회사들이 공급하고 있습니다.
분명 소프트웨어를 다운로드할 수 있는 호스트에 항상 임베디드 시스템을 붙여 놓을 것이 아니라고 한다면, 모니터 프로그램은 유일하게 디버깅에 유용합니다. 그러고 나서는 다른 방법 중의 하나로 소프트웨어를 시스템에 다운로드해서 고객들에게 선적해야 할 겁니다. 모니터 프로그램 또한 뒤에서 다시 다룰 예정입니다.
참고)
임베디드 소프트웨어 - 링커/로케이터1 (주소 재지정, 프로그램 컴포넌트 배치)
파일로부터 소스를 읽어서 링커에 적합한 오브젝트 파일을 생성하는 크로스 컴파일러의 작업은 네이티브 컴파일러와 큰 차이가 없지만, 임베디드 시스템을 위한 링커는 네이티브 링커와는 다��
ppojjaknews.tistory.com
임베디드 소프트웨어 - 링커/로케이터2 (문자열 상수, 로케이터 맵, RAM 밖에서)
링커/로케이터 두 번째 얘기를 하기를 앞서서 앞선 글에서 조금 부족했던 로케이터들이 제공하는 내용에 대해서 간략하게 적어볼 테니 복습하는 마음으로 한번 읽어보면 좋을 것 같습니다. 나��
ppojjaknews.tistory.com
임베디드 소프트웨어 개발 툴에 대한 전체 요약으로 이번 파트를 마무리하겠습니다.
- 임베디드 소프트웨어는 일반적으로 고객에게 선적될 타깃 머신과는 다른 호스트 머신에서 개발됨.
- 임베디드 소프트웨어를 개발하는 툴 체인은 일반적으로 크로스 컴파일러, 크로스 어셈블러, 링커/로케이터, 그리고 타깃 머신에 소프트웨어를 다운로드하는 도구로 이루어져 있음.
- 크로스 컴파일러는 네이티브 컴파일러처럼 같은 C 언어를 이해하지만, 출력은 타깃 마이크로프로세서의 명령어 집합을 사용함.
- 크로스 어셈블러는 타깃 마이크로프로세서에 맞는 어셈블리 언어를 이해하고 그 마이크로프로세서에 맞는 명령어들을 출력함.
- 링커/로케이터는 별도로 분리되어 컴파일되고 어셈블 된 모듈들을 실행할 수 있는 하나의 이미지를 만듦. 더해서 코드와 데이터, 스타트업 코드, 문자열 상수 같은 것들을 롬과 램의 적합한 영역에 위치시킴.
- 링커/로케이터는 코드와 데이터의 각 부분들이 어디에 위치해야 하는지 정하기 위해 세그먼트를 사용함.
- 링커/로케이터는 다양한 출력 형식을 생성함. 출력이 소프트웨어를 타깃에 다운로드하는 데 사용하는 도구와 호환이 되는지는 프로그래머가 확인을 해야 함.
- 프로그래머는 테스트를 위해서 소프트웨어를 타깃에 다운로드하는 방법을 결정해야 함. 일반적인 방법은 PROM 프로그래머, ROM 에뮬레이터, 인서킷 에뮬레이터, 플래시 메모리, 모니터 프로그램 등임.
'IT > 임베디드 시스템' 카테고리의 다른 글
디버깅을 위한 호스트 시스템에서의 테스팅2 - 인터럽트 루틴 호출 / 스크립트, 출력 파일 (0) | 2020.06.23 |
---|---|
디버깅을 위한 호스트 시스템에서의 테스팅1 - 테스팅의 목적과 기본 (0) | 2020.06.22 |
임베디드 소프트웨어 - 링커/로케이터2 (문자열 상수, 로케이터 맵, RAM 밖에서) (0) | 2020.06.19 |
임베디드 소프트웨어 - 링커/로케이터1 (주소 재지정, 프로그램 컴포넌트 배치) (0) | 2020.06.19 |
호스트와 타깃 시스템 - 크로스 컴파일러, 크로스 어셈블러, 툴 체인 (0) | 2020.06.19 |
댓글