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)
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 :)
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
KhexEdit is now flagged as unmaintained. Okteta replaces it. Closing this bug report.
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.
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
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 :)