Better user experience for setting the flashing address
igrr opened this issue · 6 comments
The default flashing address is 0x1000 which is valid for the ESP32. Newer chips expect the binary to be flashed at 0 address. We could automatically update the address field after detecting the chip.
Imho this change is not needed. Every ESP32 needs several files flashed at different addresses. The user always have to think about where to flash which file.
For example we generate merged firmware binaries for project Tasmota.
All variants for all MCUs needes to be flashed at address 0x0.
Thank you for your comment @Jason2866.
Indeed, can also generate merged binaries using esptool.py merge_bin command, they need to be flashed at the address 0.
There has been a feature request for esptool.py to produce .hex files, which would be self-descriptive — a user who got such a file wouldn't need to specify the address at all. Maybe that would be better user experience than automatically setting the flashing address.
Edit: have renamed the issue to a more general one.
Nice, generated firmware files which includes the info on which address the should be flashed would be indeed a great enhancement.
As in like the (really) old (Intel?) HEX file format?
Wouldn't that increase filesize quite a bit?
On the other hand, lots of padded zeroes can be "compressed" into 0 bytes as each line starts with the "start address" of the next 16 bytes.
Yes, Intel hex. I did an experiment using this script to generate a .hex file from an IDF build directory. With the get-started/hello_world example:
-rw-r--r-- 1 ivan staff 26K Jan 11 18:47 build/bootloader/bootloader.bin
-rw-r--r-- 1 ivan staff 174K Jan 11 18:48 build/hello_world.bin
-rw-r--r-- 1 ivan staff 558K Jan 13 17:15 build/hello_world.hex
-rw-r--r-- 1 ivan staff 238K Jan 13 17:04 build/merged.bin
-rw-r--r-- 1 ivan staff 3.0K Jan 11 18:47 build/partition_table/partition-table.bin
558kB .hex file size is almost 3 times larger than the sum of the .bin file sizes. It's also twice as big as the "merged" binary. Is that going to be a problem? I don't think so, most people probably wouldn't notice much difference. When downloading such a file, it is likely to be gzip-encoded during transfer. So the only difference is storing 558kB vs 238kB on the PC.
Yep, that's true indeed.
Most browsers will try to request a GZipped transfer and if the server accepts it, it will probably be about the same size as the bin files GZipped.