Dynamic PCLK source IDs

[jbeaurivage]

Summary

After thinking about integrating the thumbv6/thumbv7 peripherals to the v2 clocking system, I'm realizing that every peripheral that requires a PCLK clock will need to take in a new type parameter representing the GCLK source that feeds the PCLK. This is somewhat problematic as it leads to a massive amount of generic bloat, and more importantly further incompatibility between the thumbv6 and thumbv7 peripherals.

This PR allows for two parallel APIs for specifying the PCLK source ID in Pclk structs: either type-checked, or dynamically checked at runtime.

This simplifies the peripherals' type signatures, as they no longer need to carry around the source clock's ID. For example, the Adc struct had a temporary workaround where it accepted a &Pclk reference to maintain compatibility with thumbv6's v1 clocking system. This helps solve these issues, as now each peripheral can opt into either API.

Drawbacks

However this means that when using the dynamic API:

• Each peripheral instance now uses at least 1 byte of memory
• We must assert at runtime that disabling a Pclk is decrementing the correct Gclk counter

Note

This PR sits on top of #892. Relevant commit: b1c04c9. I posted it here for visibility, but it should be merged here: ianrrees#13.

[bradleyharden]

Yeah, I foresaw this a while ago and was concerned about it. That's why I wanted to implement a parallel, Dyn API for the clock system, like DynPin.

Rather than reduce the number of generics on Pclk, you might consider introducing a new, DynPclk and adding conversions to and from it for all instances of Pclk. Then you can have the peripherals take those instead. Actually, you could have them take anything that impl Into<DynPclk>.

[jbeaurivage]

@bradleyharden, I've implemented your suggestions, and I'm quite happy with it. Peripherals can pick whether they want to opt into the dynamic or type-checked PCLK API. I've changed the ADC peripheral to use the dynamic API, and it works nicely.

I guess a discussion topic will come up for each peripheral as we convert them to the v2 API, ie, whether it should be using the static or the dyn APIs, but at least we'll have the option now.