Bug 94361

Summary: khexedit does not handle .hex or .s19 files
Product: [Applications] okteta Reporter: Frieder Ferlemann <frieder.ferlemann>
Component: generalAssignee: Friedrich W. H. Kossebau <kossebau>
Status: ASSIGNED ---    
Severity: wishlist CC: kossebau, oo.o+kde
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:

Description Frieder Ferlemann 2004-12-04 01:51:48 UTC
Version:            (using KDE KDE 3.3.2)
Installed from:    Debian testing/unstable Packages

khexedit does not know how to load/save .hex or .s19 files

.hex (Intel) or .s19 (Motorola) files are frequently used to load firmware into flash/eeprom.

The formats specify both the addresses and the corresponding data, thus allowing to specify specific ranges of data which are to be modified (or left unmodified).

My request:
===========
I'd like to be able to write .hex (Intel) files by selecting areas within a file opened by khexedit and choosing "save selected as" or "export selected as" possibly with the option to specify an offset for the data.

Reading files could result in files with greyed out/normal/highlighted areas (for undefined/defined/changed areas)

Impact:
=======
Intel Hex files or Motorola S19 files are file formats used practically everywhere in embedded programming.

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 almost certain that these file formats were involved for programming the firmware.

The guys doing this stuff currently tend to stick with their Windows environment. So what?

Well, I think having drivers (or register specifications) is more likely if a larger fraction of those developers feels at home in a KDE environment.

Previous work, a good example picked:
=====================================
http://srecord.sourceforge.net/
It would be perfect if khexedit would use srecord (or part of) as an input/output filter. (File formats are near this link)
Comment 1 Friedrich W. H. Kossebau 2005-01-14 19:14:44 UTC
Hi, 

I am planning to give the new KHexEdit2 the ability to work with non-continous 
areas of byte streams. But I am curious how I should design the UI. Could you 
all please tell me perhaps about existing techniques or how your dream UI 
would look like?

I took a look at srecord and plan to use it as the information source to 
create the firmware import/export plugins so hopefully I can support all the 
formats srecord knows about :)

Thanks in advance

Friedrich

PS: If you help me fast enough I might be able to do it for KDE 3.4 :)
Comment 2 Frieder Ferlemann 2006-10-18 11:36:09 UTC
Hi Friedrich, 

sorry for the very late response (I don't think the
request has lost relevance though:^)

> But I am curious how I should design the UI.

I'd be fine if undefined regions (here 0x100 to 0x3ff) were shown as:

0000:00e0 01 23 45 67 89 ab cd ef  01 23 45 67 89 ab cd ef
0000:00f0 01 23 45 67 89 ab cd ef  01 23 45 67 89 ab cd ef
0000:0100 ??
0000:0400 01 23 45 67 89 ab cd ef  01 23 45 67 89 ab cd ef

For the file open/save (or import/export) dialogs there could be two options 
"load/save from 0xYYYYYY .. 0xZZZZZZ" and 
"load/save with offset 0x0123".

If a file is imported "on top" of another one it is very handy to have highlighted those locations which are newly imported (italics/colors/background).

Yet another highlight mode where the newly imported file (or the user) specifies a different content for the same location.

> how your dream UI would look like?

I'd be very happy if the ideas above would be implemented and think this "would just do". 
(More ideas are probably near to: http://en.wikipedia.org/wiki/Comparison_of_hex_editors)

> so hopefully I can support all the formats srecord knows about :)

Intel Hex and Motorola S19 will probably account for more than 95% of the uses. Intentionally restricting to these two would probably be a good idea as users of less widely used formats are very likely to have conversion tools at hand.

Thanks,

Frieder
Comment 3 Christophe Giboudeaux 2008-11-19 23:38:18 UTC
KhexEdit is now flagged as unmaintained. Okteta replaces it.

Closing this bug report.
Comment 4 Friedrich W. H. Kossebau 2010-01-21 01:50:24 UTC
Okteta in trunk (what will become KDE SC 4.5) just received a very initial step into the support of this: a streamencoder to the S-Record format (as used by Export/Copy As). Intel hex is next to come.
No idea yet when/if I will do support loading/importing. Supporting undefined regions and marking changes (e.g. by overloading on-top) needs some bigger works in the base models.
Comment 5 NooN 2016-02-24 16:51:31 UTC
Can Okteta now work with non-continous areas of bytes?

I have seen that there is inital support for exporting ihex.
Where would be a decoder for that/those formats be implemented?
In the libkasten?

Thanks for your work
Comment 6 Friedrich W. H. Kossebau 2016-02-24 17:36:25 UTC
Hi NooN, no, sadly still no support for non-continous areas of bytes (oha, >10 years already old, time flies).

I would be happy if you could add your ideas for your related dream UI and workflows you would like to see supported here for now, though.

Currently I am working on some bigger restructuring of the Kasten framework. So while I have plans on more features for Okteta myself (incl. non-continuous data) which are also reconsidered in the restructuring, in the next months I will not work on them.
The current Kasten has no infrastructure for the concept of loading files in multiple explicit formats, so besides needing a data model, a data view/editor for non-continous areas and decoders for .hex/.s19/etc. formats, it will also need rewiring of loading & saving infrastructure.
So its not simply done by a few more plugins right now. But the current restructuring is done with that in mind, so hopefully it will then be just a matter of more plugins, After all that's the idea of a framework.
Blocking new features for some time is the disadvantage of creating in general-purpose framework in parallel, instead of just doing what is needed for a hex editor :)