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

Vapier: /* Comments */ still dont get it

2011-03-22T23:50:29Z

‎Comments: still dont get it

Tim Bird: /* Related work */

2009-12-14T22:49:42Z

‎Related work

Tim Bird: /* Comments */

2009-12-14T22:49:20Z

‎Comments

Tim Bird: /* Comments */ add category tag

2009-12-14T22:48:36Z

‎Comments: add category tag

Tim Bird at 22:35, 14 December 2009

2009-12-14T22:35:55Z

Tim Bird: add srec editor proposal

2009-12-14T22:28:58Z

add srec editor proposal

New page

; 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 a mainboard/dvd-player/mouse/sound card/keyboard/
usb-device/graphics card/digital camera/microwave oven/mobile phone/
cdrom/car/pocket calculator/tv/modem/watch/printer/remote control/
washing machine 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 ==

@@ Line 133: / Line 133: @@
 At least being able to view and compare these files visually would be
-helpfull. (Yes I know objcopy (I did mention binutils in the proposal),
+helpful. (Yes I know objcopy (I did mention binutils in the proposal),
 srecord, hexdump and diff/tkdiff/kdiff3/xxdiff/kompare/winmerge))
 </pre>
 [[Category:Project proposals]]

@@ Line 135: / Line 135: @@
 helpfull. (Yes I know objcopy (I did mention binutils in the proposal),
 srecord, hexdump and diff/tkdiff/kdiff3/xxdiff/kompare/winmerge))
+</pre>
 [[Category:Project proposals]]

← Older revision		Revision as of 22:48, 14 December 2009
Line 135:		Line 135:
	helpfull. (Yes I know objcopy (I did mention binutils in the proposal),		helpfull. (Yes I know objcopy (I did mention binutils in the proposal),
	srecord, hexdump and diff/tkdiff/kdiff3/xxdiff/kompare/winmerge))		srecord, hexdump and diff/tkdiff/kdiff3/xxdiff/kompare/winmerge))
		+
		+
		+	[[Category:Project proposals]]

@@ Line 49: / Line 49: @@
 == Related work ==
- * okteta   http://utils.kde.org/projects/okteta/
+* okteta   http://utils.kde.org/projects/okteta/
- * srecord  http://srecord.sf.net
+* srecord  http://srecord.sf.net
- * others   http://en.wikipedia.org/wiki/Comparison_of_hex_editors
+* others   http://en.wikipedia.org/wiki/Comparison_of_hex_editors
-(* flashrom http://www.coreboot.org/Flashrom)
+* flashrom http://www.coreboot.org/Flashrom
 Related request: A five year old request for khexedit (predecessor of okteta), 20 votes

@@ Line 15: / Line 15: @@
 display like:
-00000000 02 00 08          80 fe  75 81 07 12 00 78 e5 82 ...   ..u....x..
+ 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...
+ 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
@@ Line 28: / Line 28: @@
 starting with offset 0x000b, 0x0000 or a user specified address.
-If you own a mainboard/dvd-player/mouse/sound card/keyboard/
+If you own any kind of consumer electronics product
-usb-device/graphics card/digital camera/microwave oven/mobile phone/
+it's likely that these file formats were involved.
-cdrom/car/pocket calculator/tv/modem/watch/printer/remote control/
-washing machine it's likely that these file formats were involved.
 Text tools (srecord, binutils) for these formats exist but might
@@ Line 66: / Line 64: @@
 == Comments ==