Ok , so i understand that the HEX format generated by the compiler and assembler is the intel hex format . but i have a little problem with that . i am doing some self programming applications for the AVR , and as you know , data written to the flash memory is in pages , so you load a page then you write it to the flash memory . the thing is the hex format is in records and the record size is usually or mostly or even always smaller than a page size .
besides , isn't the program data supposed to be continuous ? why does every record have it's own address pointer ? i understand that sometimes you have to write data to different sections of program memory , but am supposed to load then erase a different page every-time i load a record from the HEX file ? that does not seems practical at all knowing that most of code data is continuous .
+what's the check-sum byte in the record useful for ?
Actually the compiler and the assembler generate .o or object files.
The linker links all the object files and creates an elf file.
Then the avr-objcopy tool pulls the desired sections from the elf file to create the hex file.
The data does not have to be continuous and that is the reason for the address.
The avr-objcopy command has many options that can be used to modify the output.
You may be able to get the type of output you want by specifying commandline options.
Just change the command line options in your Makefile.
If you are not creating your hex files with your own makefile, then you are pretty much SOL and will have to use the hex file that is created by some other tool like the IDE and accept the options and hence the hex file format created by that tool.
The checksum is to used to verify that the record has not been corrupted. If you are sending the data through an unreliable transport medium such as a serial connection, it can be used to verify that the record has not been corrupted.
In the larger picture you will need to better understand the record format and write code that takes lots of factors into consideration such as the things you mention.
If you don't have full control over the hex file generation, (which is typically the case)
you will have to buffer up the hex data and preform a reassembly function to convert from the record size in the hex file (which also can vary) to the flash page size before you can flash that page.
Bootloaders do this. Avrdude also does this.
You will also have to deal with sparse hex files, which is where there are multiple discontinuous regions in the hex file.
Avrdude and self programming bootloaders handle this by knowing that during a flash update, the entire part is erased and so they can skip over those sections since they typically do a full erase up front.
Essentially, they don't have to deal with it.
If a full erase is not done up front, and sparse hex files must be supported, then a page by page erase of the full region being used can be done up front to allow the same type of processing that can be done with a full erase.
If sparse file support is not required, you can either full erase up front or erase the flash page just prior to programming.
avrdude even has options to control whether that full erase is done.
This allows the option of leaving the code/data in the sparse alone so you can update just portions of the flash.
Lots of stuff to have to deal with.
My big question is why?
Bootloaders are readily available, and ISP programming can be done using avrdude.
Note that none of the arduino bootloaders deal with hex files; that's all done on the PC-side (by avrdude), and the bootloader receives page-sized chunks of binary data.
I don't know if there are any utilities that deal with the .hex files on a record basis. The usual strategy is to allocate a chunk of memory that is as big as you could possibly need, read the .hex file into that - keeping track of at least the min and max addresses actually modified - and then pass on the "big chunk" to the next stage of processing.
DrAzzy:
The chip45 bootloader expects to be fed lines from a .hex file over serial.
chip45 looks interesting. Can the Arduino IDE be customized easily for a board to use an interfacing program that is chip45 compatible, instead of using avrdude?
i am also attempting to write a bootloader , just to develop my experience .
i am not going to erase the full program memory , i think i am just going to read every page , edit it with the record then write it again .
it will take much longer , but in this specific application it's the best choice .
What you are describing is a "packet" protocol. This dates from the early days of computing when data was stored on cassette tape and/ or sent over telephone modems. Actually, to some extent it still is and all data transfer on the Internet is sent as packets.
The concept is that the packet size represents a practical aliquot for the transfer medium, in particular an amount which if lost will require but a modest time to re-send. In other words, if you make one mistake in transmission, you do not lose the entire record. Of course this presupposes the ability to re-send missing pieces.
It also allows that in the "hex" form, the data could be printed on a page with lines of a reasonable size and in the "early days", programs were actually distributed in that form.
And that is what the transfer protocol does here given that a serial link is not an entirely reliable medium.
However, a communication "stack" (such as IP) can and does work with different packet sizes at different levels, the layers are generally connected as continuous streams, so in this case, the packets do not need to correspond to page sizes or even divisions thereof - but it is probably a little more convenient if they do. You require buffering at each level, a packet level buffer and a page level buffer (which may be provided in the EEPROM itself).
amine2:
Ok , so i understand that the HEX format generated by the compiler and assembler is the intel hex format . but i have a little problem with that .
The HEX file format is very old, from 1988 by Intel. The PDF is here.
Ray
Summary:
General Record Format
+------------------+---------------+-------------+----------------+---------------+-------------------+
| RECORD | LOAD | | | INFO | || MARK | RECLEN | OFFSET | RECTYP | or | CHKSUM || ':' | | | | DATA | |
+------------------+---------------+-------------+----------------+---------------+-------------------+
1-byte 1-byte 2-bytes 1-byte n-bytes 1-byte
Each record begins with a RECORD MARK field containing 03AH, the ASCII code for the colon (':')
character.
Each record has a RECLEN field which specifies the number of bytes of information or data which
follows the RECTYP field of the record. Note that one data byte is represented by two ASCII characters.
The maximum value of the RECLEN field is hexadecimal 'FF' or 255.
Each record has a LOAD OFFSET field which specifies the 16-bit starting load offset of the data bytes,
therefore this field is only used for Data Records. In other records where this field is not used, it should
be coded as four ASCII zero characters ('0000' or 030303030H).
Each record has a RECTYP field which specifies the record type of this record. The RECTYP field is
used to interpret the remaining information within the record. The encoding for all the current record
types are:
'00' Data Record
'0l' End of File Record
'02' Extended Segment Address Record
'03' Start Segment Address Record
'04' Extended Linear Address Record
'05' Start Linear Address Record
Each record has a variable length INFO/DATA field, it consists of zero or more bytes encoded as pairs of
hexadecimal digits. The interpretation of this field depends on the RECTYP field.
Each record ends with a CHKSUM field that contains the ASCII hexadecimal representation of the two's
complement of the 8-bit bytes that result from converting each pair of ASCII hexadecimal digits to one
byte of binary, from and including the RECLEN field to and including the last byte of the INFO/DATA
field. Therefore, the sum of all the ASCII pairs in a record after converting to binary, from the RECLEN
field to and including the CHKSUM field, is zero.
