Allow `esp32_flash` to flash another esp32 partition with another binary

[pguyot]

esp32_flash is a convenient tool, but we could improve it with flashing another binary that could be generated, for example sounds.bin for La Machine that goes into a partition named sounds.

Alternatively, the command could flash both the Erlang application and sounds.bin with proper configuration and maybe use the --skip-flashed option so sounds.bin isn't always reflashed.

[UncleGrumpy]

I think making a new task for flashing non-application binaries to flash could be very useful, this could also flash fat partition images or any other supplemental data for applications. We could have the main esp32_flash task check the configuration (and cli options) for this task and execute it if necessary as well.

[UncleGrumpy]

It might make more sense to just add a partitions parameter to the esp32_flash task configuration and cli options. This could just be a list of {PartitionName, “path/to/binary”} tuples in the config, and space separated values on the cli…
Example with extra partitions named “fat” and “sounds”

rebar3 atomvm esp32_flash —partitions sounds=binaries/sounds.bin fat=binaries/fatfs.bin

We could even simplify this more by choosing a dedicated name for an extra partitions directory in the top level of the project directory (“partitions” seems an obvious choice). Then if files in this directory match partition names on the (with an optional file extension .bin) device they can be automatically selected as candidates for flashing.

As fast as knowing for sure if these partitions need to be updated, it seems like we will need to read the existing ones and compare a sha256sum or other hash to the extra partition files.

[pguyot]

esptool has two interesting parameters for this: diff with old and skip flashed. The later does md5. This would decrease the wear.

Typically for La Machine we need the code and the sounds partition be in sync as the code has an index of every sound for an O(1) access. I added some code to check this at runtime but developers still have to figure out if they need to flash the sounds.

[UncleGrumpy]

Thanks for the tip! I will investigate letting esptool decide what needs updating.

Do you have any opinion about the configuration for flashing these extra partitions? I was already leaning towards having the esp32_flash task check the contents of a partitions directory in the root of the project (next to src/) for any files (with optional .bin extension) for matching partitions in the devices partition table. With this new information that seems to make even more sense… no configuration necessary, if we find a matching partition it will be flashed if an up to date version isn’t already present.

[pguyot]

The drawback of a partitions directory is that it cannot be in _build/... for generated stuff.

So I'd prefer a configuration in the rebar.config.

[UncleGrumpy]

Excellent point! Glad I asked before plowing ahead. Now that you point this out, I realize that more often than not, these extra binary will likely be generated at build time.