위키백과

인텔 HEX

인텔 HEX(Intel HEX)는 ASCII 텍스트 형식으로 이진 정보를 전달하는 파일 형식이다. 이것은 마이크로컨트롤러, EPROM 그리고 다른 논리 장치의 프로그래밍을 위해 흔히 사용된다. 대표적으로 컴파일러나 어셈블러는 컴퓨터 프로그램의 소스 코드를 (예를 들어 C나 어셈블리어) 기계어로 변환하고, 이를 HEX 파일로 출력한다. 그리고 나서 이 HEX 파일은 소자 프로그래머가 읽어서 ROM를 굽거나, 메모리에 올리고 실행하기 위해 목적 시스템으로 전송된다.[6]

Intel hex
파일 확장자.hex,[1] .h86,[2][3] .hxl,[4] .hxh,[4] .obl,[4] .obh,[4] .mcs,[5] .ihex, .ihe, .ihx, .a43

형식 편집

인텔 HEX는 LF나 CR로 구분된 여러줄의 ASCII 텍스트로 구성된다. 각 줄은 다수의 바이너리 숫자를 부호화한 16진수 문자를 담고 있다. 이 바이너리 숫자가 줄에서의 위치, 종류, 줄의 길이에 따라 메모리 주소나 기타의 값인 데이터를 나타낼 것이다. 각 텍스트 줄을 레코드(record)라고 한다.

레코드 구조 편집

하나의 레코드(텍스트 한줄)는 왼쪽에서 오른쪽으로 순서대로 여섯가지 필드(부분)로 나타난다.

  1. 시작코드(Start code), 한 문자, ASCII 문자 ':'(colon).
  2. 바이트 개수(Byte count), 16진수 문자 두 자리, 데이터 필드에 있는 바이트(16진수 두 문자의 쌍)의 수를 가리킨다. 최대 바이트 개수는 255 (0xFF)다. 16 (0x10) 과 32 (0x20)가 흔히 쓰인다.
  3. 주소(Address), 16진수 문자 네 자리, 데이터의 16비트 시작 주소의 옵셋 값을 표현한다. 데이터의 물리 주소는 앞서 지정된 기준 주소에 이 옵셋을 더해서 구한다. 이런 식으로 16비트 주소의 한계인 64 킬로바이트를 넘는 주소를 지정 한다. 기준 주소의 기본값은 0이고, 여러 종류의 레코드로 값을 바꿀 수 있다. 기준 주소와 주소는 항상 빅 엔디언으로 표현된다.
  4. 레코드 종류(Record type) (아래 레코드 종류 참조), 16진수 문자 두 자리, 00에서 05, 데이터 필드의 종류를 정의한다.
  5. 데이터(Data), 2n 개의 16진수 문자로 표현된 n 바이트의 데이터 열이다. 어떤 레코드는 이 필드가 빠져 있다(n이 0). 데이터 바이트들의 의미나 해석은 응용프로그래밍에 달렸다.
  6. 체크섬(Checksum), 16진수 문자 두 자리, 레코드에 오류가 없음을 입증하는데 이용될 수 있는 계산된 값이다.

색 일러두기 편집

이 문서에서 Intel HEX 레코드의 필드들은 눈에 잘 띄도록 다음처럼 색칠된다.

  시작코드   바이트 개수   주소   레코드 종류   데이터   체크섬

체크섬 계산 편집

레코드의 체크섬 바이트는 레코드에서 체크섬에 앞서 있는 모든 복호화된 바이트 합의 최하위 바이트(LSB)의 2의 보수이다. 이것은 복호화된 값(파일에 있는 16진수 문자가 아니라 그것을 두 개씩 짝지어 바이트로 해석한 값)들을 모두 더하고, 더한 값의 LSB(256으로 나눌 때 나머지)를 뽑아서 그것의 2의 보수(모든 비트를 뒤집고 1를 더한다)를 구한 것이다.

예를 들어, :0300300002337A1E 이런 레코드에서 길이부터 체크썸 전까지를 합하면 03 + 00 + 30 + 00 + 02 + 33 + 7A = E2이다. E2의 2의 보수는 1E이다.

레코드의 유효함은 체크섬을 계산하고, 계산한 체크섬과 레코드에 있는 체크섬이 같다는 것을 확인해서 검사될 수 있다; 체크섬이 다르다는 것은 오류가 있음을 가리키는 것이다. 레코드의 체크섬이 데이터 체크섬의 음수라서 체크섬을 포함하는 전체 복호화된 바이트를 더하면 LSB는 0이 된다.

줄 종료문자 편집

인텔 HEX 레코드는 각 레코드가 한 줄의 텍스트에 날 수 있도록 하나 이상의 ASCII 줄 끝 문자로 구분된다. 이것은 시각적인 가독성을 높여주고, 레코드 사이에 끼워져 있어 기계의 구문 분석 효율을 향상시키는데 이용될 수 있다.

HEX 레코드를 만들어내는 프로그램은 전형적으로 사용하는 운영 체제의 관례에 따른 줄 끝 문자를 사용한다. 예를 들어, 리눅스 프로그램은 하나의 LF(줄 바꿈, 16진수 값 0A) 문자만 사용하고, 윈도우즈 프로그램은 CR (CR, 16진수 값 0D)과 LF를 이어서 쓴다.

레코드 종류 편집

현재 여섯가지 종류가 있다.:

Hex code Record type Description Example
00 데이터 16비트 시작 주소와 데이터를 가진다. 데이터의 바이트 수가 주어진다. 오른쪽 예제는 0B 11개의 데이터 바이트를 가진다. (61, 64, 64, 72, 65, 73, 73, 20, 67, 61, 70) 이들 데이터가 0010 주소에서부터 연속으로 놓인다. :0B0010006164647265737320676170A7
01 파일의 끝 파일의 마지막 줄에 꼭 있어야 한다. 데이터 필드는 없다. 따라서 바이트 개수는 00이고, 주소 필드도 보통 0000이다. :00000001FF
02 확장된 세그먼트 주소 이 데이터 필드는 16비트 세그먼트 기준 주소다. 따라서 바이트 개수는 02다. 80x86 리얼 모드 주소와의 호환을 위한 것이다. 주소 필드는 무시된다. 보통 0000이다. 세그먼트 주소 02 레코드의 값이 16 곱해져서 이어지는 데이터 레코더의 주소에 더해져야 데이터의 물리 시작 주소가 된다. 이것은 1M까지의 주소 공간을 지원한다. :020000021200EA
03 시작 세그먼트 주소 80x86 프로세서에서, CS:IP 레지스터의 초기값을 주어진다. 주소 필드는 보통 0000이고, 바이트 개수는 04다. 첫 두 바이트가 CS 값이고, 다음 둘이 IP 값이다. :0400000300003800C1
04 확장된 선형 주소 4기가바이트까지 가능한 32비트 주소체계를 지원한다. 주소 필드는 보통 0000으로 무시되고 바이트 개수는 항상 02다. 빅 엔디안의 두 데이터 바이트가 이어지는 00 레코드의 절대 주소의 상위 16비트가이다. 04 종류의 레코드가 없는 00 레코드의 주소 상위 16비트는 기본값 0이다. 00 종류의 레코드의 절대 주소는 최근의 04 레코드 값이 상위 16비트가 되고, 00 레코드의 주소 값이 하위 16비트가 된다. :02000004FFFFFC
05 시작 선형 주소 주소 필드는 0000으로 사용하지 않고, 바이트 개수는 04다. 4바이트 데이터는 80386과 더 높은 CPU의 EIP 레지스터에 기록할 32비트 값을 나타낸다. :04000005000000CD2A

다른 이름 편집

때때로 레코드 종류의 일부만 채용한 HEX 파일 형식을 지칭하기 위해 특별한 이름이 사용된다. 예를 들어:

  • I8HEX 파일은 00과 01 레코드만 사용한다. (16비트 주소지정)
  • I16HEX 파일은 00에서 03까지의 레코드만 사용한다. (20비트 주소지정)
  • I32HEX 파일은 00, 01, 04 그리고 05 레코드만 사용한다. (32비트 주소지정)

파일 예제 편집

이 예제는 4개의 데이터 레코드와 뒤따르는 끝 레코드를 보여준다. 

:10010000214601360121470136007EFE09D2190140
:100110002146017E17C20001FF5F16002148011928
:10012000194E79234623965778239EDA3F01B2CAA7
:100130003F0156702B5E712B722B732146013421C7
:00000001FF

같이 보기 편집

글
기타

각주 편집

  1. ↑ Arnold, Alfred (2020) [1996, 1989]. 〈6.3. P2HEX〉. 《Macro Assembler AS - User's Manual》. V1.42. 번역 Arnold, Alfred; Hilse, Stefan; Kanthak, Stephan; Sellke, Oliver; De Tomasi, Vittorio. 2020년 2월 28일에 원본 문서에서 보존된 문서. 2020년 2월 28일에 확인함. […] For the PIC microcontrollers, the switch -m <0..3> allows to generate the three different variants of the Intel Hex format. Format 0 is INHX8M which contains all bytes in a Lo-Hi-Order. Addresses become double as large because the PICs have a word-oriented address space that increments addresses only by one per word. […] With Format 1 (INHX16M), bytes are stored in their natural order. This is the format Microchip uses for its own programming devices. Format 2 (INHX8L) resp. 3 (INHX8H) split words into their lower resp. upper bytes. […] Unfortunately, one finds different statements about the last line of an Intel-Hex file in literature. Therefore, P2HEX knows three different variants that may be selected […] :00000001FF […] :00000001 […] :0000000000 […] By default, variant 0 is used which seems to be the most common one. […] If the target file name does not have an extension, an extension of HEX is supposed. […] 
  2. ↑ 〈3.1. Intel 8086 Hex File Format〉. 《CP/M-86 Operating System - System Guide》 (PDF) 2 printing, 1판. Pacific Grove, California, USA: Digital Research. June 1981. 15–16쪽. 2020년 2월 28일에 원본 문서 (PDF)에서 보존된 문서. 2020년 2월 28일에 확인함.  (17 pages)
  3. ↑ 〈Appendix C. ASM-86 Hexadecimal Output Format〉. 《CP/M-86 - Operating System - Programmer's Guide》 (PDF) 3판. Pacific Grove, California, USA: Digital Research. January 1983 [1981]. 97–100쪽. 2020년 2월 27일에 원본 문서 (PDF)에서 보존된 문서. 2020년 2월 27일에 확인함. […] The Intel format is identical to the format defined by Intel for the 8086. The Digital Research format is nearly identical to the Intel format, but adds segment information to hexadecimal records. Output of either format can be input to GENCMD, but the Digital Research format automatically provides segment identification. A segment is the smallest unit of a program that can be relocated. […] It is in the definition of record types 00 and 02 that Digital Research's hexadecimal format differs from Intel's. Intel defines one value each for the data record type and the segment address type. Digital Research identifies each record with the segment that contains it. […] 00H for data belonging to all 8086 segments […] 81H for data belonging to the CODE segment […] 82H for data belonging to the DATA segment […] 83H for data belonging to the STACK segment […] 84H for data belonging to the EXTRA segment […] 02H for all segment address records […] 85H for a CODE absolute segment address […] 86H for a DATA segment address […] 87H for a STACK segment address […] 88H for an EXTRA segment address […]  [1] (1+viii+122+2 pages)
  4. ↑ 가 나 다 라 “The Interactive Disassembler - Hexadecimal fileformats”. Hex-Rays. 2006. 2020년 3월 1일에 원본 문서에서 보존된 문서. 2020년 3월 1일에 확인함.  [2]
  5. ↑ “AR#476 PROMGen - Description of PROM/EEPROM file formats: MCS, EXO, HEX, and others”. Xilinx. 2010년 3월 8일. Intel MCS-86 Hexadecimal Object - File Format Code 88. 2020년 3월 3일에 원본 문서에서 보존된 문서. 2020년 3월 3일에 확인함. 
  6. ↑ Intel: "Hexadecimal Object File Format Specification Archived 2016년 6월 7일 - 웨이백 머신", Revision A, January 6, 1988

외부 링크 편집

문서
소프트웨어
  • binex (영어), a converter between Intel HEX and binary
  • libgis (영어), open source library that converts Intel HEX and other formats
  • SRecord (영어), a converter between Intel HEX and binary (usage)
  • bincopy (영어) is a python package for manipulating Intel HEX format files.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=인텔_HEX&oldid=34818139"