ASxxxx linker output .i86 file flashed as binary

[Ian-May]

STM8 assembly language programs built using the ASxxxx (V5.20) STM8 assembler and linker are by default given names ending ".i86" - presumably indicating Intel 8086 format. stm8flash loads such a file as a binary. If you miss the word "BINARY" when flashing, it looks like flashing has been successful but of course the flash memory contains the hex records. Please consider changing your program flow so that ".bin" is required for binary flashing and anything else is just passed to the Intel hex routines which will quit with an error if the file is not valid Intel hex records. This way you will not need to add new ".xxx" entries if (when?) new hex file naming conventions appear. This will interfere with Motorola S-record support but since you have none now there will be no loss. If SDCC upgrades to a version of ASxxxx that writes ".i86" files everyone using SDCC will have this problem too.

[spth]

Assuming that everything that does not end in .bin is an Intel Hex file doesn't make much sense to me. .ihx and .hex seem to be the common endings. Maybe we could add .i86 to the list of Intel Hex endings in stm8flash?

stm8flash now has support for Motorola S-record. Maybe it will get support for ELF one day.

ASXXXX and the fork in SDCC have diverged a lot over time. While there are plans to move the SDC fork to a newer upstream version, this would require substantial effort; I don't think SDCC developers will find the time to do so anytime soon.

Philipp

[Ian-May]

I added .i86 to your source but since that wasn't going to help anyone else using ASxxxx I raised the issue. IMHO using parts of file names to indicate types belongs in the CP/M-MSDOS-Windows world i.e. "not the UNIX way". Also IMHO most software development tools will output some kind of hex record. Loading binaries would be used to load code from someone else or setting eeprom values and therefore represent the less common usage (at least for developers). (So default to hex suggestion.)

Since avrdude performs the same function as stm8flash in the AVR world, I had a look at their documentation. With avrdude file types can be indicated by appending ":i" for Intel, ":s" for Motorola and ":b" for raw binary to the file name (there are also other options). The default is automatic file type recognition without the need for ":i" for example.

I have thought of the following suggestions: 1) Add ".i86" to your source code. Add to your README that ".xxx" ending file names are required to indicate how to interpret the file contents and list all that apply. Add the same message to the -? (-h for UNIX?) switch to your executable. 2) If defaulting to binary mode, check the first byte of the file for a ":" or an "S" and issue a prompt to the console like "Possibly a hex encoded file - are you sure you want to program as a raw binary?". (At least issues a warning if someone else comes up with another ".xxx" format stm8flash doesn't understand and loads as a binary). 3) Require command line switches to specify file types (i.e. -b,-i,-m) perhaps preceding file names so "-i IntelHexFile". 4) Look at how the avrdude code does it and change to fully automatic file recognition. Retain the option to specify type to cover the case of recognition errors.

Option 1 covers the current situation - option 4 would be a worthy goal. Thank you for sharing your code, and note that I am trying to increase the utility of it rather than criticize it. Ian.

[spth]

For now, I implemented option 1, as it is the simplest. However, 4 might be a better long-term solution.

Philipp