Dynamic PCLK source IDs #978
Conversation
Manually replicated from Bradley Harden's work, rebased as 4b94fb0
This was the first "stash" in Bradley Harden's clock_v2_thumbv6m branch
The smaller chips use a simpler digital phase-locked oop, which doesn't support the DCO filter options that the larger chips do.
This could use further work - the macro now takes two booleans to indicate whether the type should be in the ApbTokens and ApbClocks structs, however each type should be in exactly one of those so it would be better for the macro to take a single boolean.
There's still some stuff to do, GclkIo etc.
Couldn't deduplicate with the feather_m4 and metro_m4 examples, because the alias used for the LED is different. Sorting that out seems like a separate project.
Reading the GCLK GENCTRL register isn't possible on the thumbv6m chips, on these there is only one GENCTRL register for the whole GCLK peripheral, in contrast to one GENCTRL per generator on the thumbv7em chips. On the thumbv6m chips, modifying GENCTRL is done by atomically writing the whole register, which has a field for the generator ID to be modified. The GENCTRL register had been modified from the GclkToken<> impl, per-field, but the state required to fill the other fields for the atomic register write wasn't available in the GclkToken<> scope. So, these GENCTRL accesses were moved up in to the Gclk<> impl. One more bit of state was added to the settings to handle the Output Enable bit.
|
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 Rather than reduce the number of generics on |
jbeaurivage
force-pushed
the
dyn-pclk-src-id
branch
5 times, most recently
from
18b5148 to
87b30c2
Compare
|
@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. |
jbeaurivage
force-pushed
the
dyn-pclk-src-id
branch
from
87b30c2 to
b2a6e8e
Compare
jbeaurivage
force-pushed
the
dyn-pclk-src-id
branch
from
b2a6e8e to
b1c04c9
Compare
jbeaurivage
force-pushed
the
dyn-pclk-src-id
branch
from
77557ad to
2b91312
Compare
3 participants
Summary
After thinking about integrating the thumbv6/thumbv7 peripherals to the
v2clocking 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
Pclkstructs: 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
Adcstruct had a temporary workaround where it accepted a&Pclkreference 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:
Pclkis decrementing the correctGclkcounterNote
This PR sits on top of #892. Relevant commit: b1c04c9. I posted it here for visibility, but it should be merged here: ianrrees#13.