delay VS esp-wifi

Took a while but this issue was fixed this year. Until then, you could compile a patched version of LLVM, or use an older nightly.

And the code generation was quite broken indeed. Most importantly the saving of registers within interrupt handlers. Hard to understand the bug, but I had documented a simple ask inline solution on the issue. It has been fixed since then.

My last experience was quite good. And I didn't notice wrong codegen.

As an aside, the inline asm combines pretty well with generics to produce custom machine code during compilation. For example I was able to reproduce the gcc-avr built-in for delays: https://github.com/avr-rust/delay/blob/cycacc/src/delay_cycl...

I recently got an Arduino Uno to blink without much hassle, very excited about the 328p having built-in support. Will be even easier when a new release of a couple libraries gets released to crates.io, hopefully soon? (https://github.com/avr-rust/delay/issues/19)

tl;dr I'm trying to figure out why the avr-delay::delay function doesn't seem to do anything when imported as an external crate, but when copy/pasting the code into my main.rs, it all works. Source code here https://github.com/avr-rust/delay

Good question! As far as I can tell from the docs, it looks like I2C is still synchronous [1], but this will be my first async embedded Rust project, so I'm still unfamiliar with the general shape and functionality of things.

For comparison, things like WiFi are definitely async [2]

[1] https://docs.rs/esp32s2-hal/latest/esp32s2_hal/i2c/index.htm...

[2] https://github.com/esp-rs/esp-wifi/blob/main/examples-esp32s...

Among these several abstractions, we can program a microcontroller device at any level we like. Additionally, we can develop code with a mix of low-level and high-level abstractions. Obviously, to make code more portable it's better to stick to higher-level abstractions. Also in addition to the above, there exists other crates supporting other functions in no-std development. These include wifi services in the esp-wifi repository, heap allocators in the esp-alloc repository, logging features in the esp-println repository, exception handlers in the esp-backtrace repository, and finally embedded storage traits in the esp-storage repository.

I haven't done much with it yet, but I'm excited about the bare-metal (no_std) rust support for the esp32c3 (as opposed to some other variants that require a custom toolchain as I understand it).

Lots of details at <https://mabez.dev/blog/posts/>, and some examples of wifi on bare-metal at <https://github.com/esp-rs/esp-wifi>.

I hope to eventually get it working with MQTT (there may be examples already, I haven't yet looked in-depth), at which point I think this will be my go-to for the majority of my IOT projects going forward!

Esp-wifi is very actively being updated, looks like C3 is supposed to work[0][1], so if you tried more than a few weeks ago it probably changed.

[0]: https://github.com/esp-rs/esp-wifi#current-support

I previously used the esp32-c3 both with bare-metal and with the idf in rust, but I did not like the experience. With the idf you get poor ide support and poor documentation and with bare metal you used to get no wifi at all, but the experience is a lot better. I have seen the new rust wifi driver https://github.com/esp-rs/esp-wifi and i am very interested, but this is still a sync driver afaik.

Also got an ESP32C3 to connect to my wifi network, which was really exciting: https://github.com/esp-rs/esp-wifi

Check the project https://github.com/esp-rs/esp-wifi, it implement bindings to the official SDK.