GeezerVison

I'd like to have some simple test for your changes. If you don't intend to write one, I will do it later, before merging.

I've added a unit test for writing segmented hex file. It takes a data64k dictionary and write it in the 'shex' format. Then the result is compared with a predefined 'shex64k' hex file.

Mateusz, do you have access to original files intended to be used by your application? I'm interested to know whether such files have start address record. I have suspicious it has CS/IP pair, so segmented addresses make perfect sense in such context. I think IntelHex library can make automatic decision about using one or another address scheme based on presence of start addr field. What do you think?

Unfortunately, I couldn't share that file with you. It is a proprietary firmware. However, it doesn't have any records other than 00, 01 and 02. It looks like it was made by the converter which didn't support linear addressing. I also looked at the Intel Hex standard and it seems that the Start Segment record is not required.
Maybe the segment addressing should be used when CS:IP is defined, but if they are zero, the Start Segment record shouldn't be written to file?

I don't really need your file, I just need to know about start address. Thank you for information.

Start record is not written if it's not here, you can see it in code.

I personally don't really like your "shex" name, because technically they're both HEX files, and two different address schemes are both defined by the same format. I'm going to think about the proper way to support your use case, but most likely I will change "shex" to something different.

I understand you as I didn't have any better solution for this fix. The name 'shex' is very ugly :) Maybe it is worth to consider the solution with automatic using of segment address when CS:IP is present? The other solution I've found on Wikipedia. Maybe all output formats should get their names from this convention. What do you think?

Quote from Wikipedia

Named formats

Special names are sometimes used to denote the formats of HEX files that employ specific subsets of record types. For example:

• I8HEX - files use only record types 00 and 01 (16 bit addresses)
• I16HEX - files use only record types 00 through 03 (20 bit addresses)
• I32HEX - files use only record types 00, 01, 04, and 05 (32 bit addresses)

I guess we can employ this naming scheme in IntelHex library. I've never heard about this naming sceme before, but it makes sense for me. Thank you for pointing at this page.

So, my plan would be like this:

1. Old name "hex" still be used for automatic decision about using record types if start address present.
2. Your patch introduces good feature for generating desired format, let's keep it.
3. Add support for i8hex, i16hex, i32hex into library, as well as to bin2hex convertor.
4. More tests :-)

Sorry for not working on your pull request. I'm looking for a new maintainer for Python IntelHex project. I hope someone will help.

Your patch is partially superseded by #41