Naming and bin/hex

[jcw]

Would it be an idea to also optionally generate .bin and .hex files?

These images can be a great tool to quickly validate the next step, i.e. uploading and running. One approach could be to rename the bin/ directory to build/ (it's not really a "bin" you'd want to add to any PATH env, after all), and then create extra pseudo targets for "bin" and "hex" to build the requested format for all the images.

A full build for testing then becomes this one-liner: make all bin hex

[karlp]

I'm not against generating bin's, but I'd like to see more people realise that they can get better behaviour using .elf files, with less error prone steps like remembering what address to flash to. The whole "how to flash" section is the last real piece of this repo, as it's massively openended.

I certainly don't see any reason for both bin and hex :)

[jcw]

Well, st-flash wants .bin files, wherease stm32flash wants hex files. In GDB, hex is easier than bin.
Sure, there is elf for debugging - but if you want to do over-the-air updates, you want bin.
The address is always the same on stm32.

[karlp]

in gdb, you just use elf. also, there's far more than stm32 supported here :) I've got ti, silabs, atmel/microchip parts as well to come in :) And like I said, I'm philosophically opposed to letting people keep using stone age tools :)

[jcw]

"Stone age tools": that's neither argument nor philosphy, that's opinion. Goodbye.

[karlp]

Look I'm not against it, I know they're still heavily used, I just want people to know that are are other, arguably better options. Like I said, the whole "how to flash" the files generated here is still a hairy open problem. The boards with integrated debuggers are "easy" but the rest are hairy.

[jcw]

Your perspective is development, this was about deployment. Let’s not dwell on it, life’s too short.

[karlp]

fixed in 31a01d3 thanks for the push

[jcw]

Thanks. I appreciate your willingness to make such a change despite your reservations.