Various issue 819 fixes

[ianrrees]

Summary

While investigating #819 I made a few documentation changes, added ability to tune the DPLL filters, and added a method to check the DFLLRDY status bit. Although the actual issue in 819 turned out to not be in our code, these might be useful additions.

Checklist

• All new or modified code is well documented, especially public items
• No new warnings or clippy suggestions have been introduced - CI will deny clippy warnings by default! You may #[allow] certain lints where reasonable, but ideally justify those with a short comment.

[jbeaurivage]

Thank you for this. Did we reach a conclusion wrt the chicken-egg problem of having the DFLL defaulting to being on-demand, and therefore won't be ready unless there's a GCLK requesting it before it's turned on? Is it just a matter of documenting that behavior, or there still more work to be done?

I think an alternative that has been suggested is to force the user to explicitly choose whether they want on_demand to be on or off. That would be a good place to document the implications of leaving it on.

Otherwise I'm pretty happy with this!

[ianrrees]

I think that the on_demand thing isn't too big of a footgun; it only shows up if a check is added that the PLL is running, which in most cases probably isn't necessary. We could put it in an example code along with a comment about why it is where it is.

Which reminds me, I think I noticed some example code in clock v2 that wanted an update... Will aim to look at that soon so let's not merge this quite yet.

[jbeaurivage]

The "code that wanted an update" was most likely in the ADC PR (#814) if that's of any help!

[jbeaurivage]

@ianrrees were there any discussion points still open about this PR? Any more work to be done?

[ianrrees]

I've rebased to the current master, and updated that example code to use Fugit - think this should be good to go, thanks!