# Espflash v4

## Rationale

While the v3 releases of `cargo-espflash` and `espflash` work reasonably well, there are a number of outstanding issues which need resolving, and it is not especially extensible with regards to supporting new functionality/features.

With our current efforts to stabilize the HAL I think it's important to provide high-quality tooling along with the stable release when it's ready. This further enhances the developer experience and provides more incentive to use our software.

## Brainstorming

These are possible changes to be made for the new major release. We don't necessarily need to address all points, some will require some further investigation and/or discussion.

- Experiment with storing chip metadata in a serializable format which can then be used to generate targets automatically, so that we don't need to write any/much additional code to support new devices
- This may not be feasible, however is worth exploring IMO
- Perhaps we can rework our traits (and/or add more) to make this process simpler, too
- Try to make bootloaders and partition tables more configurable/flexible
- Also probably I should finish rewriting `esp-idf-part` and use that...
- Try to eliminate extraneous dependencies where possible
- [SGA]: Not really a Rust dependency, but worth exploring imho: https://github.com/esp-rs/espflash/issues/711
- Simplify/clean up error handling
- We have *a lot* of errors, perhaps this can be reduced?
- Try to reduce library API surface as much as possible
- Ideally, we should only expose what is absolutely required by library users (e.g. `probe-rs`)

## Planning

### Things to Implement

- Add support for additional image formats (e.g. mcuboot, direct-boot) and make this extensible in a non-breaking way to allow additional formats to be supported as needed
- https://github.com/esp-rs/espflash/issues/701
- https://github.com/esp-rs/espflash/issues/706
- Stubs and bootloaders should be updated. Bootloader updates will require us to get the app description stuff working.
- https://github.com/esp-rs/espflash/issues/695
- https://github.com/esp-rs/espflash/issues/720
- We should come up with some sort of a story for OTA, as this is pretty important functionality. Even if we just have some documentation that's better than nothing, maybe we can do more with tooling, but unsure.
- https://github.com/esp-rs/espflash/issues/298
- Rework the `save-image` subcommand to fix current issues and add new functionality
- https://github.com/esp-rs/espflash/issues/713
- https://github.com/esp-rs/espflash/issues/714
- https://github.com/esp-rs/espflash/issues/715
- Improve the command-line interface, make more options available for all relevant subcommands
- https://github.com/esp-rs/espflash/issues/684
- https://github.com/esp-rs/espflash/issues/655

### Things to Investigate

- Determine which additional features should be implemented (e.g. secure boot, flash encryption, etc.)
- https://github.com/esp-rs/espflash/issues/642
- https://github.com/esp-rs/espflash/issues/191
- Explore which other subcommands need reworking, removal, or what new subcommands need to be added
- Eliminate the `cargo-espflash` package
- This should be reasonably well received as long as we can port over the functionality unique to this application (i.e. reading cargo config, package metadata, resource detection when using IDF, etc.) and provide a similar experience when using `espflash` as a cargo runner
- Rework the code for reading eFuse values to be more similar to how this is handled in `esptool.py`, making it easier to adopt functionality as needed
- Explore existing Python tooling to determine which other tools we can adopt functionality from (e.g. `espefuse.py`, `espsecure.py`, etc.)
- Investigate ivmarkov projects as it may be useful to have some of the features merged in espflash:
- https://github.com/ivmarkov/espfactory
- https://github.com/ivmarkov/espsign