Add support for dual ADC mode and injected sampling based on interrupts

[Jacke-debug]

Add code in complementary PWM to be able to generate interrupts from the timer.
Made pac adc vals imports public to be able to re-export them to the user.

[Jacke-debug]

@Dirbaio and thoughts on this? This PR was mainly done to cover the needs in the project I'm working on. I noticed that the current state of the ADC module is rather far from the capabilities of the ADC peripherals, if there is some roadmap or vision for the ADC module I could maybe help with the development. As and example the existing read function for regular ADC channels reconfigures the ADC for each read operation which is problematic in high performance or timing critical applications.

[Kaikallon]

Could we get some attention on this PR perhaps? Assuming that the merge conflict are resolved, could this be merged?

[Jacke-debug]

@lulf can you please have a look at this PR given that I fix the conflicts?

[Jacke-debug]

@lulf ping

[Jacke-debug]

@lulf or @Dirbaio can one of you please review, its been quite some time now without any feedback

[lulf]

Sorry for the delay. There's many PRs trying to tackle this and/or similar issues I think, what's your thought on

#4583
#4450

[Jacke-debug]

#4450
I think the idea from the title is very good. I also try to separate the reading from configuraiton of ADC within this PR (bit for the injected conversion) as this is how I have seen it in C-projects.

I think it would be better if the exisitng "read" method was removed as having both that one and the two new methods from that PR makes the module a bit confusing. Maybe there is a point in keeping "read" as it is for legacy reasons?

Some renaming could also help
"prepare_read" -> "configure_regular_sequence" (aligned with the name for inejcted channel configuraiton in this PR)
"read_without_preparing" -> "trigger_regular_conversion_and_await_result"

In the future we may also need to extend support for auto-triggered regular conversions.

#4583
These changes are bit more foreign to me. If the idea is to get average values over more samples there is also the built in Oversampler module in the ADC which could be used. I don't think I understand the usecase fully.

Nether of those PR cover my needs tho as I need to use the injected ADC channels as the exact moment of sampling is important for my applicaiton.

[Jacke-debug]

@lulf what is the idea behind the different ADC files, g4.rs, v1.rs, v2.rs etc?

Is the intention to keep different versions for different processors or shall the latest vx.rs be used for all and be adapted through conditional configuration?

[lulf]

@lulf what is the idea behind the different ADC files, g4.rs, v1.rs, v2.rs etc?

Is the intention to keep different versions for different processors or shall the latest vx.rs be used for all and be adapted through conditional configuration?

The vX is intended to be a version of the peripheral that more than one stm32 family shares (often they are quite similar).

Sometimes a version is just too family specific so you get things like g4.