Intel hex, Motorola srecord and pipe support - [merged]

[DavidGriffith]

In GitLab by @radiomanV on Sep 30, 2019, 09:26

Merges ihex -> master

Here is, the intel hex, motorola srec and pipe support. This will address the issue #114.

The command line switch -f <format> is used to specify the file format. This option is useful when reading chips to specify exactly in what format to save the output file.
For ex: minipro -p w49f002u -r file.hex -f ihex will read the specified chip and save the file in Intel hex format.
minipro -p w49f002u -r file.srec -f srec will save the file in Motorola srec format.

When writing chips there's no need to specify the file format because the file format is automatically recognized. For Intel hex file the three formats (ihex8, ihex16 and ihex32) are automatically handled, no need to specify the exact format, that's why the format specifier is ihex. Also when reading chips if the data size is up to 64Kb the file will be saved in ihex8 format (jus plain hex records, no segment/linear address records are inserted). If the data size exceeds 64Kb then the ihex32 format is used. No ancient 80286 16bit segmented address ihex16 is used when saving files. The same strategy is used for the Motorola srecord format.

The -f option was used previously for the firmware update but i decided to use the lowercase -f for the format specifier and the uppercase -F for the firmware update option. The man file is updated to reflect this change.

The 'piping' support is implemented for both read from stdin and write to stdout. The stdout was cleaned of error messages in one of my previous merge request. The only requirement is to pass the pipe character - instead of a file name. That's all.

For example: head -c 256k </dev/urandom | srec_cat - -bin -o - -intel -Address_Length=4 -obs=16 | minipro -p w49f002u -w-
This is how i tested most of the hex/srec parsers when reading from stdin. So 256kb of random binary data is generated then converted from binary to intel hex by the srec_cat utility and finally the converted data is passed to our minipro which will read this data, convert it to binary by decoding the intel hex format from stdin and write it to the specified chip. Note the -r- which tells to read from stdin instead from a regular file. This is just a test command to test the ihex/srec parsers. Don't use this in real life (convert from binary to ihex then from ihex to binary).

minipro -p atmega8a -w file.hex will read the file.hex and write it to the specified chip. Note there's no -f ihex, the file format is automatically recognized.

minipro -p atmega8a -r file.hex -f ihex when reading the format should be specified (-f srec or -f ihex)
If no format is specified then the file will be saved as binary format (this was the only format recognized till now).

You can also read a chip and write the data to the stdout like this: minipro -p w49f002u -r- -f ihex. Sure you can pass the output to another command line tool with | for other processing, etc.

Because of two critical bugs were accidentally discovered by me while testing various chips i decided to fix them here in the same merge request. One is already reported (#150) the other one i think is somewhat old (i found some mentions in #44). I fixed it too (the extended fuse is wrongly read/written).

Damn, i hate to write documentation in other language :) I hope that someone with will update the man file.

[DavidGriffith]

Merging and then updating the manpage after the merge. Gitlab currently has a problem if I were to do the merge manually which leads to the merge being marked as "closed" rather than "merged".

[DavidGriffith]

merged

[DavidGriffith]

mentioned in commit a72787cf87caa19882af70360ed3b21f98db05d2

[DavidGriffith]

In GitLab by @radiomanV on Sep 30, 2019, 13:33

Super! thanks David. Should we bump the version to 0.5?