Björn Quentin

as mentioned in #88 we had similar problems before which were related to wrong timestamp calculations which shouldn't be the case now (unfortunately I was never able to reproduce it...

> Can we merge this meanwhile? Generally yes - but the CoEx example needs to get fixed

You might want to try opt-levels 1,2,"s" and "z" for release (in debug things tend to be way to slow so you really want release builds). The assert happens in...

I don't want to be annoying but unfortunately the coex example doesn't compile yet ``` ❯ cargo "+nightly" run --example coex --release --target riscv32imc-unknown-none-elf --features "esp32c3,embedded-svc,wifi ,ble" Compiling esp32c3-hal v0.3.0...

I think there are some more details available: https://github.com/esp-rs/esp-wifi/blob/60e57efa839590b915dc0cabd9bdc28afa0a0b19/src/binary/include_esp32c3.rs#L3977-L3999 But only a fraction of that gets mapped here: https://github.com/esp-rs/esp-wifi/blob/60e57efa839590b915dc0cabd9bdc28afa0a0b19/src/wifi/os_adapter.rs#L43-L53 My gut feeling for now is to show how to implement...

Maybe we could try to do the same steps (manually scan and then try to connect) in esp-idf (probably it doesn't matter if we use C or Rust) and see...

I also don't know any no-std/no-alloc HTTP server but probably writing something very simple should be possible in a few lines of code. (While a real HTTP server is definitely...

#95 adds an oversimplified example showing a single server-socket used to do something that "looks like" HTTP - a real HTTP server is definitely out-of-scope for this crate

Closing since we now have an example using server sockets - as said a real HTTP server is out-of-scope for this crate

Update: It doesn't happen in development mode and also doesn't happen with an `opt-level `