Fixes problems with the rtc::Rtc abstraction and refactors to use the new rtc::modes abstractions.

[kyp44]

Summary

It was discovered that the rtc::Rtc abstraction does not work properly, at least on SAMx5x targets. This was previously reported and discussed in issue #501, but it looks like a cause was never really nailed down.

This PR effectively re-writes the RTC with the same API, expanding and leveraging the new private rtc::modes abstractions that were written for the RTC-based RTIC monotonic.

Refer the to commit message for some additional details.

I wanted to get this PR going, and the code is ostensibly complete. However, I have only tested all implemented RTC features/modes on the PyGamer (SAMD51) so far, see here. I have a Metro M0 (SAMD21) on order with a display, so I will test on that as well and report back when it arrives.

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 @kyp44! I'll take some time to review in depth, meanwhile I'd still want to wait for the SAMD21 tests to be complete.

[jbeaurivage]

@kyp44, I tried testing this with an SAMD21 board. It seems like there is something making the RTC code stall forever. Here is my test code:

#![no_std]
#![no_main]

use atsamd_hal::ehal::delay::DelayNs;
use atsamd_hal::rtc::Rtc;
use atsamd_hal::time::KiloHertz;
use defmt_rtt as _;
use panic_probe as _;

use bsp::hal;
use bsp::pac;
use feather_m0 as bsp;

use bsp::{entry, pin_alias};
use hal::clock::GenericClockController;
use hal::delay::Delay;
use hal::prelude::*;
use pac::{CorePeripherals, Peripherals};

use hal::fugit::RateExtU32;

#[entry]
fn main() -> ! {
    let mut peripherals = Peripherals::take().unwrap();
    let core = CorePeripherals::take().unwrap();
    let mut clocks = GenericClockController::with_external_32kosc(
        peripherals.gclk,
        &mut peripherals.pm,
        &mut peripherals.sysctrl,
        &mut peripherals.nvmctrl,
    );
    let pins = bsp::Pins::new(peripherals.port);
    let mut red_led: bsp::RedLed = pin_alias!(pins.red_led).into();

    // STALLS HERE!
    let mut rtc = Rtc::count32_mode(peripherals.rtc, 10_000.kHz(), &mut peripherals.pm);
    //

    loop {
        rtc.delay_ms(200);
        red_led.set_high().unwrap();
        rtc.delay_ms(200);
        red_led.set_low().unwrap();
    }
}

Digging a little further, looks like the stall occurs when trying to read the SWRST bit of the RTC mode 0 (rtc/modes.rs:173):

// rtc/modes.rs
// Wait for the reset to complete
// SYNC: Write (we just read though)
// STALLS HERE!
#[hal_cfg(any("rtc-d11", "rtc-d21"))]
while rtc.mode0().ctrl().read().swrst().bit_is_set() {}
//

[kyp44]

Thanks for the detailed info! I've got my new kit in hand, and have been working porting my PyGamer code to test the RTC to the Metro M0. I don't have a debugger, but I bought a display with it, so I'll definitely be able to fully troubleshoot this very soon.