Modem split cfg issue

[dragazo]

I'm getting an instance of Modem from Peripherals::take, but can't split it to access the WifiModem. It looks like there's a Modem::split method, but it's protected by a cfg on esp_idf_esp32_wifi_sw_coexist_enable. My first issue is that even with CONFIG_ESP_COEX_SW_COEXIST_ENABLE=y in my sdkconfig.defaults file, this doesn't enable the method, even with a fresh compile. But more importantly, do we even need this part of the cfg at all? Modem::split takes self by value, so it could just directly return self.1 and self.2 by value. Simply moving a normal Rust object that already exists should require no special cfg considerations. So it seems like a simple #[cfg(not(esp32s2))] would suffice and fix my issue. The same would apply for Modem::split_ref.

[ivmarkov]

@dragazo But if you don't have CONFIG_ESP_COEX_SW_COEXIST_ENABLE enabled, even if you are able to unconditionally split the peripheral, you won't be able to use Wifi and BT simultaneously? So yeah, I can make this code unconditional, but what is the point if you cannot instantiate simultaneously the BT and WIFI stack on top of the split modem?

[ivmarkov]

Hmm, I take my words back: the docu says that this option enables "software" coexistence, implying that by default these can coexist, based on hardware (how/if this works reliably I don't know). So yeah, I can remove this option for you if it makes life easier for you.

[dragazo]

@ivmarkov Well I'm actually ok with keeping the cfg if it's unclear in the docs if it's ok to have both, but I'm not sure why the method wasn't enabled even when i did set that option in my sdkconfig.defaults. Also, for my specific use case, I actually only need the wifi modem. I'd have to double check the docs, but if there's not an issue with having either or (even without coexist), we could just add methods like into_wifi(self) and into_bluetooth(self) that only get one of them.

My bypass for this issue isn't bad by any means, so this isn't a huge issue. It basically just means i have to drop the modem object (for my own sanity) and instantiate wifi directly with the unsafe constructor. My only gripe is that that line is the only unsafe code in my entire project lol

[ivmarkov]

If you don't want to use wifi and BT simultaneously, why are you trying to split the modem peripheral in the first place? Just pass the damn thing to WifiDriver or EspWifi and be done with it! :-)

but I'm not sure why the method wasn't enabled even when i did set that option in my sdkconfig.defaults.

This I somehow highly doubt, as every other option configured so far in sdkconfig.defaults has worked correctly. Are you sure that your sdkconfig.defaults file is even picked up and is being set at the correct place (binary crate root, if you are NOT using a cargo workspace; otherwise set the path to the config with an env var)

[dragazo]

@ivmarkov Is there just some magic trait that lets it be used as an instance of EspWifi? Cause I haven't found one. I'm not using WifiDriver and it works fine - just need the EspWifi instance

I know the sdkconfig.defaults file is being used cause i had to change settings in it to get everything working. It looks like the cfg here is using a deprecated config name, which might be the issue. I might need to set both to get it to allow it. But if that's the case it should probably be a cfg any.

[Vollbrecht]

if you look here https://github.com/esp-rs/esp-idf-svc/blob/master/src/wifi.rs#L1015 EspWifi is just a thin wrapper around WifiDriver that does convenience stuff for you. If you look at the signature of WifiDriver https://github.com/esp-rs/esp-idf-svc/blob/master/src/wifi.rs#L333 you can see it takes the modem as a Peripheral here . To look how it than does the "some magic" have a look here were Wifi and BT got mapped to that https://github.com/esp-rs/esp-idf-hal/blob/master/src/modem.rs

[ivmarkov]

I really don't think there is anything more than a misunderstanding here. If you believe otherwise - reopen this bug and clarify.