You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is just a fluke idea, though in the past the one thing that we suggest many people to do , If things were failing to run, to use the --no-stub option. So if that is a valid strategy, it would raise the question, why not automate it.
pros:
potentially improve the "out of box" experience
reduce support request where we just say "please run with --no-stub".
cons:
do not help reduce root cause of problem why its not running with the stub on the particular target
The text was updated successfully, but these errors were encountered:
At this point I think we're probably going to switch back to the old C stub used by esptool.py. The Rust stub is buggy and needs a fair bit of work, we were supposed to be getting some help with that repo but that never really materialized.
We have plenty of other things to work on right now and we really gain nothing by having the stub written in Rust to be honest, it's just kind of a distraction right now IMO.
If we decide to switch then I guess we will need to evaluate whether or not this is still necessary, perhaps that will be enough to resolve any outstanding issues. Will let you know what we end up doing with regards to this.
We ended up merging the legacy stub, so hopefully the stub-related issues are resolved as a result. Will leave this open for now just so we can verify that, though.
This is just a fluke idea, though in the past the one thing that we suggest many people to do , If things were failing to run, to use the
--no-stub
option. So if that is a valid strategy, it would raise the question, why not automate it.pros:
cons:
The text was updated successfully, but these errors were encountered: