taking a look at an actual AVR .hex file just now i can see it's not actually that simple:
But it IS simple.
Here's your example:-
if each line has a checksum and then say 16 bytes of data then thats 17 bytes per line. Each byte is a 2 hex digit value ie 00->FF.
So count back 17 x 2 digits and a space - you now get:-
Next step. If each line has 16 data bytes (+ a checksum) then 16 in hex is 10. So we would expect the number at the lhs to be going up in steps of 10. And it does! Just add some more spaces:-
:100000 00 29C043C042C064C69CC535C6DAC506C611
:100010 00 6BC517C53AC039C038C037C036C035C007
:100020 00 34C070C932C00000010008004000000167
:100030 00 00040000010008002000400080000001D2
:100040 00 00043031323334353637383.........
ok: so lets refer to wikipedia rules:-
1. Start code, one character, an ASCII colon ':'.
2. Byte count, two hex digits, a number of bytes (hex digit pairs) in the data field. 16 (0x10) or 32 (0x20) bytes of data are the usual compromise values between line length and address overhead.
3. Address, four hex digits, a 16-bit address of the beginning of the memory position for the data. Limited to 64 kilobytes, the limit is worked around by specifying higher bits via additional record types. This address is big endian.
4. Record type, two hex digits, 00 to 05, defining the type of the data field.
5. Data, a sequence of n bytes of the data themselves. 2n hex digits.
6. Checksum, two hex digits - the least significant byte of the two's complement sum of the values of all fields except fields 1 and 6 (Start code ":" byte and two hex digits of the Checksum). It is calculated by adding together the hex-encoded bytes (hex digit pairs), then leaving only the LSB of the result, and making a 2's complement (either by subtracting the byte from 0x100, or inverting it by XOR-ing with 0xFF and adding 0x01). If you are not working with 8-bit variables, you must suppress the overflow by AND-ing the result with 0xFF. The overflow may occur since both 0x100-0 and (0x00 XOR 0xFF)+1 equal 0x100. If the checksum is correctly calculated, adding all the bytes (the Byte count, both bytes in Address, the Record type, each Data byte and the Checksum) together will always result in a value wherein the least significant byte is zero (0x00).
So looking at the first line with some extra spaces:
:10 0000 00 29C043C042C064C69CC535C6DAC506C6 11
Rule 1 = it starts with a colon - yep
Rule 2 = number of chars that follow=10hex ie 16 digits
Rule 3 = address as 4 hex digits = 0000
Rule 4 = record type 00 = data record
Rule 5 = data digits. So 16 x 2 hex digits
Rule 6 = Checksum. in this case '11'
So it totally conforms to the spec.
So the programmer will write out 16 bytes of data starting at address 0000 where the 16 data bytes are 29 C0 43 C0 42 C0 64 C6 9C C5 35 C6 DA C5 06 C6