RTC peripheral can be used without configuring the RTC clock

[RobinMcCorkell]

Summary: it's possible to compile a program that uses the RTC peripheral, which hangs when the RTC tries to sync since the RTC does not have a clock enabled at that point. This is primarily caused by the Rtc constructors taking a Hertz value rather than a clock token, e.g. RtcClock.

The documentation for GenericClockController::rtc states:

... Returns a typed token that proves that the clock has been configured; the peripheral initialization code will typically require that this clock token be passed in to ensure that the clock has been initialized appropriately.

Except the RTC peripheral does not actually use this functionality.

---

I spent a good few hours wondering why my naive RTC code was leading to a hang, then I realized I hadn't set up the RTC clock. The correct code is something like:

let mut clocks = GenericClockController::with_internal_32kosc(
    ctx.device.GCLK,
    &mut ctx.device.PM,
    &mut ctx.device.SYSCTRL,
    &mut ctx.device.NVMCTRL,
);

let rtc_clock_src = clocks
    .configure_gclk_divider_and_source(ClockGenId::GCLK2, 1, ClockSource::OSCULP32K, false)
    .unwrap();
clocks.configure_standby(ClockGenId::GCLK2, true);
let rtc_clock = clocks.rtc(&rtc_clock_src).unwrap();

// Notice rtc_clock is not used, i.e. it's possible to forget to set up the clock at all.
let rtc_clock_freq = Hertz(32_768_000); // or rtc_clock.freq()
let rtc = Rtc::count32_mode(ctx.device.RTC, rtc_clock_freq, &mut ctx.device.PM);