SW3 isn't correctly cfg'd away when it's used by embassy multicore executor

[MabezDev]

esp-hal/esp-hal/src/system.rs

Lines 306 to 307 in 19db509

	#[cfg(not(all(feature = "embassy", multi_core)))]
	pub software_interrupt3: SoftwareInterrupt<3>,

The embassy feature no longer exists on esp-hal, therfore this cfg doesn't work correctly.

[Dominaezzz]

Ideally this should be solved with the type system rather than a cargo feature.
Something along the lines of esp_hal_embassy::init(&clocks, timer, software_interrupt3, .....).

One shouldn't need special code in the hal to add support for an async runtime.

[bugadani]

While I agree with the idea of a type-system solution, I'm not entirely happy about the boilerplate necessary for this and I'd prefer re-introducing the feature instead. We can hide it from the users (depending on esp-hal-embassy could automatically enable the feature), and third party runtimes can do whatever they wish.

[Dominaezzz]

and third party runtimes can do whatever they wish.

What happens when you have multiple async runtimes then? How do you ensure they're not going to fight over the 4th software interrupt?

Side note: There should probably be an AnySoftwareInterrupt type or something.

I agree that the boilerplate isn't fantastic but it's the only way to know what parts of your software is using what piece of hardware. Coming from C/C++ embedded space, I'd be very happy to not have the issue where two different libraries are fighting over the same peripheral. Even esp-idf's libraries have this problem.
I think not having this problem is more valuable than saving some boilerplate.

This particular bit of boilerplate can be fixed with a macro I think.

[bugadani]

I believe it is worth optimising for the common use case. Third party runtimes can deal with pass-interrupt-by-value if they need to.