chore: update embassy's executor rev sync to 0.2

[elpiel]

Closes #162

I'm not 100% how to test this change and probably the same should be done for esp-hal crate as well.

[bjoernQ]

Yes, I think it should also be done in esp-hal

This unfortunately breaks the build

error[E0433]: failed to resolve: unresolved import
   --> /home/runner/.cargo/git/checkouts/embassy-9312dcb0ed774b29/e2516bb/embassy-executor/src/raw/mod.rs:294:19
    |
294 |     Thread(crate::arch::ThreadPender),
    |                   ^^^^
    |                   |
    |                   unresolved import
    |                   help: a similar path exists: `core::arch`

For more information about this error, try `rustc --explain E0433`.
error: could not compile `embassy-executor` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
Error: Process completed with exit code 101.

[elpiel]

@bjoernQ yes, a given feature should be enabled depending on the platform
What would be the best way to add this feature though?
I believe that for tests it should enable the std feature while for riscV or cortex-m should enable other features respectively.

[bjoernQ]

I see - probably it's easiest to set the feature in the example-espXX folders - since those are target specific there we could set arch-xtensa for ESP32, S2 and S3 and arch-riscv for all others

[elpiel]

Okay great. I will make sure to update the pull request.

[elpiel]

I'd also like to update the revision of embassy-net. Any thought on this?

[bjoernQ]

I'd also like to update the revision of embassy-net. Any thought on this?

I guess there shouldn't (hopefully) be a problem since embassy-net is now using smoltcp from crates.io - would be good to have it updated since there is now also DHCP support in embassy-net

[elpiel]

seems that there's an issue when building embassy-executor for platforms that do not support AtomicBool

error[E0432]: unresolved import `core::sync::atomic::AtomicBool`
 --> /home/elpiel/.cargo/git/checkouts/embassy-9312dcb0ed774b29/e2516bb/embassy-executor/src/arch/riscv32.rs:9:30
  |
9 |     use core::sync::atomic::{AtomicBool, Ordering};
  |                              ^^^^^^^^^^ no `AtomicBool` in `sync::atomic`

I'll have to make a PR to embassy to fix this. see embassy-rs/embassy#1381 (comment)

Also, I've messed up the name of the feature for riscv, so I've pushed a fix for that too.

[elpiel]

The fix for atomics is another apparently, I've added the configuration to riscv examples:

embassy-rs/embassy#1381 (comment)

I've also enabled the embedded-svc when the wifi is enabled as I was getting a lot of these errors;

error[E0433]: failed to resolve: use of undeclared crate or module `embedded_svc`
  --> esp-wifi/src/wifi/mod.rs:10:5
   |
10 | use embedded_svc::wifi::{AccessPointInfo, AuthMethod, Protocol, SecondaryChannel};
   |     ^^^^^^^^^^^^ use of undeclared crate or module `embedded_svc`
   |
help: there is a crate or module with a similar name
   |
10 | use embedded_hal::wifi::{AccessPointInfo, AuthMethod, Protocol, SecondaryChannel};
   |     ~~~~~~~~~~~~

error[E0432]: unresolved import `enumset`
  --> esp-wifi/src/wifi/os_adapter.rs:12:5
   |
12 | use enumset::EnumSet;
   |     ^^^^^^^ use of undeclared crate or module `enumset`

error[E0432]: unresolved import `enumset`
  --> esp-wifi/src/wifi/mod.rs:11:5
   |
11 | use enumset::EnumSet;
   |     ^^^^^^^ use of undeclared crate or module `enumset`
...

Should be ready for review 👍

[bjoernQ]

The RISCV-IMC targets still run into some problems with atomics when linking

[elpiel]

Since I'm not very competent with those targets can you elaborate what can be causing this issue?
Or share some docs to check whether this target supports atomic operations?

Edit: I double checked the esp-hal repo and it seems that I also have to add this config:

  # comment the cfgs below if you do _not_ wish to emulate atomics.
  # enable the atomic codegen option for RISCV
  "-C", "target-feature=+a",

[bjoernQ]

Since I'm not very competent with those targets can you elaborate what can be causing this issue? Or share some docs to check whether this target supports atomic operations?

Edit: I double checked the esp-hal repo and it seems that I also have to add this config:

  # comment the cfgs below if you do _not_ wish to emulate atomics.
  # enable the atomic codegen option for RISCV
  "-C", "target-feature=+a",

Good catch! Thanks

Seems like we need to also modify the options for S2 😢 Sorry for the inconvenience!

[elpiel]

No worries @bjoernQ.
What else do we need to include for the atomic operations on S2?

Here's the hal crate's config.toml I've taken the atomic operations enabling from:
https://github.com/esp-rs/esp-hal/blob/main/esp32s2-hal/.cargo/config.toml

[bjoernQ]

Oh, you already added that line, I somehow missed that.

So, I tried it locally and it builds fine with the Xtensa-Rustc 1.68 but with 1.69 I get the same errors we see in CI

I cannot make sense of this yet - will try to look into that. If I don't find a clue, probably my colleague (who in on vacation this week) will definitely know what to do

[bjoernQ]

And also ... this isn't related to your PR but is a 1.68 vs 1.69 thing 😲

[bjoernQ]

Okay ... seems I got it to compile with the following in examples-esp32s2/.cargo/config.toml

[target.xtensa-esp32s2-none-elf]
runner = "espflash flash --monitor"

rustflags = [
    "-C", "link-arg=-Tlinkall.x",
    "-C", "link-arg=-Trom_functions.x",

    # enable the atomic codegen option for Xtensa
    "-C", "target-feature=+s32c1i",
    # Tell the `core` library that we have atomics, even though it's not
    # specified in the target definition
    "--cfg", 'target_has_atomic',
    "--cfg", 'target_has_atomic="8"',
    "--cfg", 'target_has_atomic="16"',
    "--cfg", 'target_has_atomic="32"',
    "--cfg", 'target_has_atomic="ptr"',
]

[build]
target = "xtensa-esp32s2-none-elf"
 
[unstable]
build-std = [ "core" ]

Basically just added "--cfg", 'target_has_atomic',

[elpiel]

Fixed. I might have missed a few lines* when copy-pasting I suppose

[bjoernQ]

Nice! Everything seems to work fine (besides some problems with optimization levels introduced by Xtensa-Rust 1.69)

There is one little annoyance introduced:
warning: skipping duplicate package embassy-stm32h7-examplesfound at..............cargo\git\checkouts\embassy-9312dcb0ed774b29\e2516bb\examples\stm32h7``

Seems like in that commit stm32h5 and stm32h7 examples both use embassy-stm32h7-examples as the package name

Not the end of the world however

[bjoernQ]

Is there a reason to not use the commit of the executor that is used in esp-rs/esp-hal#488 ?
While it's not really needed would be nice to have it aligned (and also it will remove that warning I talked about in the message before)

[elpiel]

Yes, it's best to keep them aligned as I've experienced issues with wifi Device impl when there are 2 different version of the a given trait.
I haven't come back to this issue but last time I was unable to make the wifi crate work.

Let me update the revision.

[bjoernQ]

Oh sorry, I only meant to set the embassy revision to fb27594
Since this depends on the released/published HALs it now runs into problems resolving versions of embedded-hal stuff

[elpiel]

I've patched the esp hal versions with the ones from the repo.
I suppose we can update to latest versions once they are released. Other option is to use an older revision of embassy but it will take some time to find which one.

[bjoernQ]

Probably better to go for the later version of embassy. I hope the next release of the HAL will be in not-too-distant future.
Unfortunately, there were some breaking changes in esp-hal. Especially timer now additionally take a &mut PeripheralClockControl. Only the examples are affected however

[bjoernQ]

I can also take over this ... just let me know

[bjoernQ]

Closed in favor of #166