texzk / hexrec Goto Github PK

E.g. to get/set the header of a Motorola record file, get/set start address, etc...

Wait until all GitHub Actions hosted runners support it.

(currently missing: macOS 13)

Hi,

thanks for this great package. I found some issues, though. The blocks.find method's documentation reads like it was done for applying binary search (just like locate_at() does). But this is apparently not the case, there is only a simple slow loop inside.

Also, the current implementation does not look into subsequent blocks. That's not a problem if you have applied merge() before but in case someone has forgotten this, the find operation might throw the exception incorrectly.

However, since the find() method is probably already in use by people, it might make sense to deprecate it and document its issue, and create an alternative method like "bin_find". Which would also return a list of block ids, not just one.

Add an align method to flood (pad) blocks such that their boundaries become aligned to the required alignment.

https://linux.die.net/man/1/xxd » Examples

I try to input a s19 file and fill value, but output s19 file format was S315.... I except it is S325..

Multi-line return value description generates messy HTML

Hi,

from what I see, when a user calls something like:

    save_blocks(out_res_path, blocks, record_type=IntelRecord, split_kwargs={"columns": columns})

The resulting file always contains an additional block which looks like:

:020000040000FA
:0400000500000000F7

From what I know about IntelHEX format, that is probably a Linear Address Record or Extended Linear Address Record. But those were not part of the data to store. They may have some purpose for somebody but in my usecase, they end up without contents.

So my wish would be to have a parameter of save_blocks to NOT add such dummy blocks unless there is data content for them, or maybe even make that behavior default.

In merge_records, there is:

    blocks = []
    for records in data_records:
        blocks.extend([r.address, r.data] for r in records)
    blocks = Memory.collapse_blocks(blocks)

But this doesn't filter out the header records, which leads to header data corrupting memory.

This is to be consistent with the usage of Python sequences

import hexrec.records as hr

default_values = [0xFF for _ in range(256)]

hr.save_chunk('TEST.s19', bytes(default_values), 0X1f00)

memory = hr.load_memory('TEST.s19')

memory.fill(0X1f00,0X1f05,bytes([0x01,0x02,0x03,0x04,0x05]))

hr.save_memory('TEST.s19', memory)

the first position is 0x02( position: 0x1f00 )
the last position is 0x01(position: 0x1f04)

the sequence is 0x02 0x03 0x04 0x05 0x01

E.g. to add a header to the motorola output file

By default, xxd treats input files as-is, thus rendering a hexadecimal record file by its file content (plain text file) instead of its semantics (binary segmented memory data).

Define a few CLI arguments (e.g. --input-format like other CLI commands) to make CLI xxd treat the input record file as a memory image.

In Memory.__getitem__():

            if isinstance(step, self.items_type):
                blocks = read(blocks, start, endex, step, self.items_join)
                **blocks = flood(blocks, pattern=step, join=self.items_join)**
                items = self.items_join(items for _, items in blocks)
                return items

the call to flood() raises an exception when the range [start:endex] is empty.

It is required to call flood() with start and endex arguments.

Error while running "cut" command with generated exe from PyInstaller,

\hexrec\pyinstaller\win-x86>hexrec cut -s 0x04201800 -e 0x04201850 test-input.hex test-output.hex
Traceback (most recent call last):
File "hexrec_cli.py", line 7, in
File "site-packages\hexrec-0.2.1-py3.8.egg\hexrec_main_.py", line 43, in main
File "site-packages\click\core.py", line 829, in call
File "site-packages\click\core.py", line 782, in main
File "site-packages\click\core.py", line 1259, in invoke
File "site-packages\click\core.py", line 1066, in invoke
File "site-packages\click\core.py", line 610, in invoke
File "site-packages\hexrec-0.2.1-py3.8.egg\hexrec\cli.py", line 264, in cut
File "site-packages\hexrec-0.2.1-py3.8.egg\hexrec\cli.py", line 110, in find_types
File "site-packages\hexrec-0.2.1-py3.8.egg\hexrec\records.py", line 2028, in find_record_type_name
KeyError: 'unsupported extension: .hex'
[21792] Failed to execute script hexrec_cli

Even specifying input file format throws invalid choice error,

hexrec-0.2.1-py3.8.egg\hexrec\pyinstaller\win-x86>hexrec cut -s 0x04201800 -e 0x04201850 -i intel test-input.hex test-output.hex
Usage: hexrec cut [OPTIONS] INFILE OUTFILE
Try 'hexrec cut --help' for help.

Error: Invalid value for '-i' / '--input-format': invalid choice: intel. (choose from )

But, running directly from the command line tool works OK
hexrec\pyinstaller\win-x86>python -m hexrec cut -s 0x04201800 -e 0x04201850 test-input.hex test-output.hex

System environment details:
OS : Windows 10,
Python v3.8.3

Installed hexrec from source and also tried with pip install
Same error is seen on Windows sub-system for Linux as well.

Attached input .hex file and generated hexrec.exe for reference.
win-x86.zip

The templated autosummary stuff is a mess.
I'd rather generate some automatic stuff, then switch to manual page formatting, as soon as the API gets stable enough.

Dependency to enum34 causes problems on Python >=3.6 e.g. using pyinstaller.
Ideally if "install_requires" in setup.py checks sys.version_info and only for python <3.6 it adds the num34.

Only required for Python 3.3 or older, which are not targeted anymore.

Currently Microchip SQTP is parsed as Intel HEX (commit 9c8a344).
There are issues converting to/from memory role because Microchip SQTP addresses are expressed in words (2 or 4 byte wide) instead of direct bytes.
Thus, Microchip SQTP requires dedicated management for apply_records, update_records, and the like.

When I try to import the hexrec.records using newest python it says there is no module:
import hexrec.records as hr
ModuleNotFoundError: No module named 'hexrec.records'

It is installed though, and worked in python 3.9.

For both input (as done per hexdump) and output.

Remove any references to hexrec.blocks.

The module is going to be removed from the package from hexrec >= 0.3.0

Using the bytesparse package, which replaces the hexrec.blocks module.