RFC: Remove support for ESP8266

[jessebraham]

While esp8266-hal was still being actively developed and maintained at the time of this tool's inception, that is not longer the case. While there has been a small amount of interest in using this device with Rust, there has not been any commitment from anybody to make this feasible.

Given that we have no intentions of supporting this device, and its EOL date is creeping ever closer (2026), maybe we should just drop support for the ESP8266. Users will still have access to esptool.py and espflash@2.x.x, both of which will support the ESP8266, if it's really needed.

[SergioGasquez]

I think its reasonable to remove support for ESP8266 in espflash@3.x.x, as it is not very used, the hal is not maintained, and they can always use old versions of espflash or esptool to flash it.

[elpiel]

From the community I've heard quite a few people that still have ESP8266 and want to use it.
Even if the hal is not maintained I think keeping the support can be vital for rewriting projects or using boards that you have laying around.

There are also new boards that come out with ESP8266 so it might be worth keeping it around.

[jessebraham]

There are a number of factors that motivated this:

1. esp8266-hal has been in maintenance mode since May 30th, 2022. There have been maybe a single-digit number of people who have contacted me regarding this package since switching to maintenance mode; a couple initially seemed interested in getting development started there again, however nothing ever came of this. This paired with the lack of downloads from crates.io, it really does not seem there is much interest from the community.
2. This project (espflash) also has received very few consistent contributions from the community. I've largely been responsible for this application throughout its life (especially since the original author stopped contributing), and I just really do not have the time or interest in continuing. It does everything I need it to do for my day-to-day work, so I have been spending my time implementing and maintaining features which I don't even use myself. I have passed the reigns off to @SergioGasquez, however he also has other projects for which he is responsible. Without consistent contributions from the community, it's very difficult to justify maintaining features which essentially nobody seems to be using, from my perspective at least.

I have a soft spot for the ESP8266 as well, and know it's still reasonably popular in the open-hardware community. Unfortunately we have very limited resources and plenty of other projects which require attention, so we really need to see the community step up and A) communicate their interest in this device and B) contribute to the HAL, this application, and other supporting libraries.

[elpiel]

Ok, I agree with your points.
Then I really hope you support the rest of the no_std ecosystem like you've done so far even if we lose support of one or two chips.

[jessebraham]

I personally have every intention of supporting all other devices, and will do everything I can to provide as consistent experience between them as possible. Unfortunately the ESP8266 is just a bid of an odd duck.

I'll also add that nothing is permanent, if there is sufficient demand and we have people willing to contribute, it's always possible support could be re-added in the future. I just can't commit to this at this time.

[MabezDev]

I don't have many thoughts on this really, but do we have some indication of the maintenance burden of the esp8266? We chose to remove direct-boot in esp-hal because it was eating up developer time but maybe if esp8266 support isn't bogging us down it's okay to stay?

[SergioGasquez]

do we have some indication of the maintenance burden of the esp8266?

I think the main pain point of maintaining esp8266 in the future is updating the stubs, is the only target not supported in esp-flasher-stub so we need to use the C-stub. And, maybe if we introduce new features, having them working in esp8266 may also give us some trouble

[jessebraham]

Removing both the direct-boot and esp8266 image formats also allows us to get rid of the ImageFormat trait and some other associated enums. Not the end of the world to keep it in, just would be nice to simplify things.

[SergioGasquez]

ESP8266 current open issues: #472 and #471