I2S reconfiguration support

[bbutkovic]

trafficstars

I'm working on a project and I'd like to be able to reconfigure the I2S channels on-the-fly.

The IDF already has support for that so it would be great if we could also do it here.

I'm willing to work on this, in fact I started already, going to post a WIP PR.

[ivmarkov]

Can you describe a bit your specific use case, and in particular - why dropping and re-creating the driver would not work for your case?

[bbutkovic]

I'm writing a sort-of wrapper around the I2S driver that I may or may not publish later as a crate. I hold the driver within my struct wrapper, meaning when I want to drop and re-create the driver I have to also keep ties to the peripherals or pass them into the function that calls for re-configuration. This is all doable but by using the API above it would make it a little bit cleaner and easier to reason about.

[skibon02]

Hi! I also need reconfiguration possibility in my scenario.

why dropping and re-creating the driver would not work for your case?

Could you please explain, did you mean using clone_unchecked() for keeping peripherals and reusing them to create a new instance of I2sDriver with a new configuration?

By making use of i2s_channel_reconfig_* functions of esp-idf it would make managing peripherals much easier in code. Ideally, it'd be great to have uninit(self) method which would return participating peripherals as a tuple. But a variety of i2s modes can make it difficult

[ivmarkov]

Hi! I also need reconfiguration possibility in my scenario.

why dropping and re-creating the driver would not work for your case?

Could you please explain, did you mean using clone_unchecked() for keeping peripherals and reusing them to create a new instance of I2sDriver with a new configuration?

You can always create the driver with the peripherals passed by &mut instead of by moving them in the driver. This way, if you drop the driver, you can re-use the peripherals in the new instance of the driver.

[skibon02]

passed by &mut instead of by moving them in the driver

Oh, thanks, i've missed this feature! But considering reconfig implementation, I can make a PR with attempt to add reconfigure and uninit methods.

The only thing I want to know is a preferred way to keep I2S mode metadata, are generics ok? (e.g. I2sDriver<StandardMode, I2sRx>, I2sDriver<TdmMode, I2sBiDir>)

[ivmarkov]

passed by &mut instead of by moving them in the driver

Oh, thanks, i've missed this feature! But considering reconfig implementation, I can make a PR with attempt to add reconfigure and uninit methods.

The only thing I want to know is a preferred way to keep I2S mode metadata, are generics ok? (e.g. I2sDriver<StandardMode, I2sRx>, I2sDriver<TdmMode, I2sBiDir>)

If - as part of the reconfiguration - you plan to change the mode (i.e. to go from StandardMode to TdmMode) this cannot be done without dropping and re-creating the driver, as type-state modeling cannot be done any other way...

[skibon02]

I don't want to change mode during reconfiguration, but everything else. And we need to track which mode was selected upon driver creation to call appropriate reconfigure function.

[ivmarkov]

I don't want to change mode during reconfiguration, but everything else. And we need to track which mode was selected upon driver creation to call appropriate reconfigure function.

This can be done in many ways. You can also track it with a simple enum. That is, unless the reconfigure functions have different signatures for each mode.