CELF Project Proposal/Create tool to edit ihex or srec files


 * Summary : Upgrade an existing Hex editor to be able to read/write Intel Hex and Motorola S-record files


 * Proposer : Frieder Ferlemann

Description
The ihex and srec formats can have an important role in an embedded developers toolchain. The formats specify both the addresses and the corresponding data, thus allowing to specify specific ranges of data which are to be modified. While editors for binary files exist for linux they all seem to lack import and export functionality for these formats.

Reading two files consecutively should result in a hexadecimal display like:

00000000 02 00 08         80 fe  75 81 07 12 00 78 e5 82 ...   ..u....x.. 00000010 60 03 02 00 03 79 00 e9 44 00 60 1b 7a 00 90 00 `....y..D.`.z...

where the corresponding bytes are either highlighted (when the definition in the 1st file differs from the 2nd file), normal (if same), obmitted or greyed out (if there is no definition in either of the files), be in color1 if only defined in the 1st file and color2 if only defined in the 2nd.

Writing a selection of the buffer (lets assume byte 0x000b to 0x000f in the example above) to an .hex or .s19 file should be possible starting with offset 0x000b, 0x0000 or a user specified address.

If you own any kind of consumer electronics product it's likely that these file formats were involved.

Text tools (srecord, binutils) for these formats exist but might present an inhibition for developers which are used to a graphical toolchain on other platforms.

Embedded developers targetting these devices (especially 8-bit targets) typically do not use Linux as a host platform. If there is a win over then I'd hope for better linux support (f.e. upgrading the firmware of some of these devices would not require buying the license of another operating system) and I'd hope for more openness with respect to protocols and linux drivers.

An anecdotical contribution relating to the importance of having developers for a specific platform: http://www.youtube.com/watch?v=8To-6VIJZRE


 * Outlook : In the long run it might be possible to interface to flashprogrammers.

Related work

 * okteta  http://utils.kde.org/projects/okteta/
 * srecord http://srecord.sf.net
 * others  http://en.wikipedia.org/wiki/Comparison_of_hex_editors
 * flashrom http://www.coreboot.org/Flashrom

Related request: A five year old request for khexedit (predecessor of okteta), 20 votes http://bugs.kde.org/show_bug.cgi?id=94361

Persons to contact:
 * Friedrich W. H. Kossebau (okteta)
 * Peter Miller (SRecord)


 * Scope : 2 weeks+ (depending on the internal structure of the hex editor)

Comments
Wolfgang Denk wrote: Hm... is this really needed? Ignoring the often existing restrictions like segment structure, alignment to flash erase blocks etc.  in  an image file (which render such image editing useless and can be dealt with  easier  by  regenerating  the  files  through  a  normal  build process),  typical image conversions / manipulations can be performed often quite easily by combinations of standard tools like objcopy and the like...

I doubt that a general purpose tool can be designed that covers  all potential use  cases, and combinations of the already existing tools are usually pretty efficient.

Mike Frysinger wrote: if you want something to just edit files, how about: objcopy -I ihex -O binary "$1" "$1.tmp" && khexedit "$1.tmp" && objcopy -I binary -O ihex "$1.tmp" "$1" && rm -f "$1.tmp"

Frieder Ferlemann wrote:

> Hm... Is this really needed?

Short answer: Yes, these formats were implemented for a reason.

Long answer falls into 3 parts which basically say: a) others seem to need it, b) others implemented it, c) plausible usage scenarios exist

Ad a) there were some votes for the bugs.kde.org request

Ad b) rethorical question: should the authors of     (http://www.hexedit.com/ http://www.kibria.de/frhed.html http://www.dataman.com/ http://www.conitec.net/ ....)     be informed that they should drop intel hex/motorola s19      support as that feature is a non-issue?

Ad c) Take an 8-bit device with an 1k bootloader, a serial number,     a program and calibration data crammed into 8k      (or 16k/32k/64k if you are lucky - evidently this is not a linux target:)     How do you to communicate the following usage cases:      1) upgrade only the program, 2) upgrade calibration data      but not the program, 3) upgrade bootloader, program and calibration data but do not the touch serial number, 4) upgrade bootloader and program but do not the touch     serial number and do not touch calibration data.      This *can* be the matter of transmitting a *single* .hex or .s19      file respectively!      (you can do with binary files and some binutils/srecord scripts too but you'd have to talk the customer into installing some tools in a Windows environment first, possibly get around limitations in command line length in above mentioned environment and then try to educate the customer to run a batch file from some directory where some files should reside and then feed the resulting file somewhere else. For one or the other reason one probably wouldn't do this for long:)     Or consider a binary file with the content of the nonvolatile      CMOS memory on a PC in which you'd want someone else (or a      group of people) to set two bytes at two different positions      to a specific value: You can tell to load the binary file into      the editor, then load the .hex/.s19 file over it, then save      again as binary.

At least being able to view and compare these files visually would be helpful. (Yes I know objcopy (I did mention binutils in the proposal), srecord, hexdump and diff/tkdiff/kdiff3/xxdiff/kompare/winmerge))

Mike Frysinger wrote: Your examples don't really sound like justification to me. It sounds like you simply need a tiny amount of metadata surrounding the transfer to communicate whatever needs updating. Plus, how is this relevant at all to "tool for editing files"? Plus plus, you yourself already said there are multiple tools that can already edit ihex/srec files natively.

I don't see anything new/useful/innovative in this proposal.