There is no guarantee that an Intel Hex record only contains 16 bytes of data. The RECLEN field is one byte, and the Intel Hex Format Specification allows it to be up to 255. In practice, it's usually a lot less than that though, typically in the range you suggest.

Note that in addition to the overhead associated with the non-data fields and newlines, each data byte is represented with two ASCII characters. Thus, the size overhead factor of an Intel Hex file must always be greater than 2, but as you point, out, could be much larger.


Yes, it is a very poor choice, and as you suggest, abuse of widely accepted terminology. This assembler is something of a Swiss Army Knife of 8051 tools: it tries to replace a lot of big tools with a single integrated compact one, but doesn't really excel in any area. The big problem with the abuse of the OBJ extension though is that some device programmer software automatically attempts to interpret such files as raw binary data, rather than as the Intel Hex files they are. Thus, when dealing with them, I always either rename them to have a HEX extension or check the buffer before I program the chip.

Humor aside, Erik is correct in referring to this tool as "pseudo-professional". This tool is just that: reasonably solid, but not really suitable for more than trivial projects at the professional level. It's about as barebones as you can get in an 8051 assembler, and is appropriate for small tasks or those who choose to pass on the features provided by a more advanced tool chain.

--Sasha Jevtic