Hence saving gives me a big file with mostly zeros.
2] The HEX file does not fill the entire address range, but everything I've tried so far pads the file/data/memory out to the maximum address, and in the case of the PIC, that range extends to a few bytes beyond the logical address range (where the configuration words are stored). The target of interest is a PIC microcontroller with 14 bit instructions, and the problems I am encountering are - 1] The HEX file is organised as 16 bit byte pairs, so searching for ASCII constants is not easy as in the 'decoded' section the bytes of interest (the constants) are all spaced out, appearing as double bytes. The ability to edit either the ASCII or the HEX (which most binary editors also do) is really a must-have for such an editor. My specific use case is I would like to search for a string in the hex file (as ASCII), replace it, and rewrite the hex file. Apart from filling "unaddressed memory" with zero, it does very well. I had an older version of HxD that didn't import/export hex files, but I have just tried the latest version and it looks good.
This should be easy to implement, but would be a bit of a hack. Of course the typical scenario with one chunk of data at some start address would just make it necessary to remember the start offset somewhere (comment, additional file) and apply it when saving. Which is probably why it wasn't done yet (AFAIK). the editor would need to keep track of a potentially unlimited (worst case: chunks = filesize/bytes per line) number of chunks of data, split/merge them dynamically if needed, consider fill patterns correctly etc. And while it's certainly feasible to keep data in editable chunks, I would think it's quite a bit of additional effort to do it right. AFAIK none of the major commercial hex editors offers this feature. But my understanding still is that the OP was looking for a tool that would allow editing the specific ranges inside a hex file and then automatically also saving only the exiting/edited memory ranges. So 32bit ranges are problematic and storing the hex file again will either store one big chunk or you need to save ranges specifically and merge them later. But as discussed before, they will typically load a hex file into a default memory range that starts at 0 and ends after the last byte of the hex file. Of course there are tons of hex editors out there which allow loading from and saving to different text file formats (Intel hex, Motorola S-records). I'd be honestly surprised if it even had an import functions for Intel hex files. UltraEdit just has a (basic) hex editor mode to display/edit the current file in a raw data view.
0 kommentar(er)
