fix(bsc): wifi connection; need to wait until the status is right #84
Conversation
previous commit was using a custom loop but this PR comment[1] points to a better way `wait_status_with_timeout` method. this method was dependent upon using the latest versions of the dependencies, esp. esp-idf-svc. Without these updates to respective crates, Cargo was unhappy with conflicts of base crates like embeddad-hal. [1] #84 (comment)
|
This works now, thanks to you all - @Dajamante , @justahero and @SergioGasquez. I see wifi connecting and the output is @BriocheBerlin , @Mirabellensaft could you please try my branch too and maybe it works? @Dajamante maybe flashing may work for you this time? |
|
I am not sure why there is a cargo deps conflict in the docker check test run. this does not happen to me on my local. |
|
The conflict doesn't show when running intro/hardware-check or intro/hello-world, but it does for me when trying to build intro/http-client/exercise |
You may need to update the dependencies in all the projects, as |
|
I made a PR against this PR branch, forgot that the branch was on the main repo - I'm more used to the fork and branch model |
|
with this branch, my wifi works! Can you rebase, so it's on the same state as main, minus your changes? Just to make sure it fixed the right issue |
Remove comments
Add ESP_IDF_TOOLS_INSTALL_DIR
Cleanup of environment variables
Use ESP_BOARD as ARG
|
@Mirabellensaft I rebased and pushed but now i see stuff 🙈 i did not commit... |
|
Hello! I was ooo for a few days, can someone update me on the state of this PR? Why it was changed to draft? Thanks in advance! |
previous commit was using a custom loop but this PR comment[1] points to a better way `wait_status_with_timeout` method. this method was dependent upon using the latest versions of the dependencies, esp. esp-idf-svc. Without these updates to respective crates, Cargo was unhappy with conflicts of base crates like embeddad-hal. [1] esp-rs#84 (comment)
|
@SergioGasquez it was changed to draft primarily because this PR/branch is being used to test the material internally. Until our checks are all green, it was suggested this be draft. Fear not, this will be merged once all the folks at FS have finished their checks. |
|
@SergioGasquez we have pinged on the #85 already but not sure why #85 is a draft as well? |
|
FYI, I have a related issue, which this PR seems to PARTIALY fix. Currently, when flashing/monitoring via the USB/JTAG port, the Wifi dosn't connect.
Testing with this PR, USB/JTAG with monitor, Wifi now connects about 75% of the time, (three out of four tries it works, one it fails.) So much more reliable, but not always. Can actually debug now with this PR, with Wifi connecting. (generally). Trace from a fail in case it is usefull: Note: There is no 'delay' when it is waiting for status, it seems to blow right through that line. Certainly dosn't wait 2100s ! |
previous commit was using a custom loop but this PR comment[1] points to a better way `wait_status_with_timeout` method. this method was dependent upon using the latest versions of the dependencies, esp. esp-idf-svc. Without these updates to respective crates, Cargo was unhappy with conflicts of base crates like embeddad-hal. [1] esp-rs#84 (comment)
previous commit was using a custom loop but this PR comment[1] points to a better way `wait_status_with_timeout` method. this method was dependent upon using the latest versions of the dependencies, esp. esp-idf-svc. Without these updates to respective crates, Cargo was unhappy with conflicts of base crates like embeddad-hal. [1] #84 (comment)
previous commit was using a custom loop but this PR comment[1] points to a better way `wait_status_with_timeout` method. this method was dependent upon using the latest versions of the dependencies, esp. esp-idf-svc. Without these updates to respective crates, Cargo was unhappy with conflicts of base crates like embeddad-hal. [1] #84 (comment)
|
Solved by #99 |
I was trying to flash my esp32-c3 board and while I was successful at that, my wifi did not connect.
It turns out that the code in the bsc vendoered lib did not lend way to check for the status in a loop until it is either connected of disconnected. This is unhelpful because there are three states of the connection status enum and one of them is
Connectingwhich may take a few ms.Caveat: I am new to this so I did what I thought was the right thing. Please help improve this if you think I made a mistake.