Clocking API V2 (for thumbv7em) #450

glaeqen · 2021-06-09T15:57:43Z

Authors: @bradleyharden, @glaeqen, @vcchtjader

Summary

New clocking API allowing to build a typesafe chain of dependent clock sources, generic clock generators and peripheral channels.

Motivation

Current clocking API assumes the following workflow:

let mut clocks = GenericClockController::with_{external,internal}_32kosc(...PAC...);
let gclk9 = clocks.configure_gclk_divider_and_source(ClockGenId::GCLK9, 1, ClockSource::DFLL48M, false);
let adc0_clock: Adc0Clock = clocks.adc0(&gclk9);

This API has the following limitations.

By default the GenericClockController constructor configures and provides an opinionated set of clock sources and generic clock generators that cannot be changed afterwards. Following clock configuration is set for thumbv7em.
- GCLK0 (Generic Clock Generator 0) is driven by DFLL48M (48MHz) through GCLK5 (divider: 24 -> 2MHz) through Pclk1 (Peripheral Channel 1) through DPLL0 (multiplier: 60 -> 120MHz)
- GCLK1 is driven either by XOSC32K (use_external_32kosc) or OSCULP32K (use_internal_32kosc)
It is not possible to set up additional clock sources within the framework of current clocking API (without hacking around PACs).
Once you setup the Clock Source - GCLK pair, it is impossible to change it later.
Once you setup the GCLK - PeripheralChannel pair, it is impossible to change it later.

Main clock locked to 120MHz by HAL, even though being acceptable in basic scenarios, is a serious design flaw that severely diminishes flexibility of a HAL and might either encourage users to hack unsafe solutions on top of existing abstractions or discourage them from using the HAL altogether.

Having these points in mind and also the fact that current clocking API implementation would benefit from refactoring anyway, striving for improvement seems to be fully motivated and justified.

Detailed design

Introduction

ATSAMD clocking system assumes 3 types of major building blocks:

Clock sources (referred to further on by ClkSrc)
Generic Clock Generators (referred to further on by Gclk)
Peripheral Channels (referred to further on by Pclk)

Properties of ATSAMD clocking system:

Gclks depend on ClkSrcs in a N:1 relationship
Pclks depend on Gclks in a M:1 relationship
Some ClkSrcs can depend on some Pclks
Specifically:
- For thumbv7em-based MCUs
  - Pclk0 can serve as a reference clock provider for ClkSrc:Dfll48M
  - Pclk1 can serve as a reference clock provider for ClkSrc:Dpll0
  - Pclk2 can serve as a reference clock provider for ClkSrc:Dpll1
- For thumbv6m-based MCUs
  - Pclk0 (on thumbv6m Peripheral Channels are called GCLK Multiplexers) can serve as a reference for ClkSrc:Dfll48M
Some ClkSrc can depend on some other ClkSrcs
Specifically
- For thumbv7em-based MCUs
  - 32Khz signal of ClkSrc:Xosc32K can serve as a clock source for ClkSrc:Dpll{0, 1}
  - ClkSrc:Xosc{0, 1} can serve as a clock source for ClkSrc:Dpll{0, 1}

Mapping HW model to Rust

In order to model one-to-many type of relationship between dependencies a few additional concepts/abstractions were introduced.

`Enabled` type and its helper types/traits

Enabled type wrapper represents a clocking component in its enabled state while also holding an information about current amount of dependencies (usually 0 upon construction). This amount of dependencies is embedded into the type via second generic parameter leveraging typenum::{UInt, UTerm} types.

pub trait Counter {} /* implemented for every `typenum::Unsigned` */

pub trait Increment: Counter {
    /* implemented for every `typenum::Unsigned` and `Enabled` */
    type Inc: Counter;
    fn inc(self) -> Self::Inc;
}

pub trait Decrement: Counter {
    /* implemented for every `typenum::Unsigned` and `Enabled` */
    type Dec: Counter;
    fn dec(self) -> Self::Dec;
}

pub struct Enabled<T, N: Counter>(pub(crate) T, PhantomData<N>);

Via specialized implementation blocks for this type (like for Enabled<Gclk<G, H, U0>) it is possible to introduce special behaviour; e.g. fn disable will only exist for clocking component having U0 current users.

`SourceMarker` trait and its subtraits

This marker trait unifies family of more specific traits. These ones are essential during a construction fn ::{new, enable} and deconstruction fn ::{free, disable} of clocking components as they provide information to the constructed/deconstructed type what its source is (shown in the example later) and which variant of source (associated constant) is applicable while performing a HW register write.

pub trait SourceMarker {}

pub trait GclkSourceMarker: SourceMarker {
    const GCLK_SRC: crate::pac::gclk::genctrl::SRC_A /* GclkSourceEnum */;
}

pub trait PclkSourceMarker: GenNum + SourceMarker {
    const PCLK_SRC: crate::pac::gclk::pchctrl::GEN_A /* PclkSourceEnum */;
}

pub trait DpllSourceMarker: SourceMarker {
    const DPLL_SRC: crate::pac::oscctrl::dpll::dpllctrlb::REFCLK_A /* DpllSrc */;
}

pub trait GclkOutSourceMarker: GenNum + SourceMarker {}

These are implemented by marker types corresponding to existing clocking abstractions e.g.:

pub enum Pll1 {}
impl GclkSourceMarker for Pll1 {
    const GCLK_SRC: GclkSourceEnum = GclkSourceEnum::DPLL1;
}
// or
pub enum Dfll {}
impl GclkSourceMarker for Dfll {
    const GCLK_SRC: GclkSourceEnum = GclkSourceEnum::DFLL;
}

`Source` trait and its subtraits

This trait represents a source of clocking signal while subtraits its more specialized flavours (source of signal for Dpll, Pclk, Gclk, etc.).

pub trait Source {
    fn freq(&self) -> Hertz;
}

pub trait GclkSource<G: GenNum>: Source {
    type Type: GclkSourceMarker;
}

pub trait PclkSource: Source {
    type Type: PclkSourceMarker;
}

pub trait DpllSource: Source {
    type Type: DpllSourceMarker;
}

pub trait PrivateGclkOutSource: Source {
    fn enable_gclk_out(&mut self, polarity: bool);
    fn disable_gclk_out(&mut self);
}

pub trait GclkOutSource: PrivateGclkOutSource {
    type Type: GclkOutSourceMarker;
}

These are implemented by corresponding specialized types of Enabled e.g.:

impl<G, D, M, N> GclkSource<G> for Enabled<Dpll<D, M>, N>
where
    G: GenNum,
    D: DpllNum + GclkSourceMarker,
    M: SrcMode,
    N: Counter,
{
    type Type = D;
}

Regardless of how complicated it might seem to look, it can be roughly understood as: Enabled Dpll peripheral can be a source of signal for any Gclk.

`*Token` types

Unfortunately, PAC::Peripherals granularity is too low for them to be useful when spliting clocking system into such small, semi-independent pieces. In order to solve this problem, we consume PAC at the very beginning and return a set of tokens that internally use appropriate RegisterBlock directly, retrieved from a raw pointer . It is safe because register regions managed by different tokens do not overlap. Tokens cannot be created by a user; they are provided during initialization and do not expose any public API. Memory accesses are read/write-synchronized (Chapter 13.3; p. 138).

`Source/SourceMarker` traits usage in an API

This is a slightly simplified example of how more less every clocking component that relies on one-to-many depenedency relationships is implemented

impl<G, T> Gclk<G, T>
where
    // `GenNum` is a generalization of a Gclk compile time parameters
    // (e.g. ordering number via associated constant)
    G: GenNum,
    // Practical application of `SourceMarker`; it makes a connection between
    // `Source` and a `Gclk` used by it
    T: GclkSourceMarker,
{
    pub fn new<S>(token: GclkToken<G>, source: S) -> (Self, S::Inc)
    where
        S: GclkSource<G, Type = T> + Increment,
    {
        // .. implementation details ..
        let gclk = Gclk {
            token,
            /* ... */
        };
        (gclk, source.inc())
    }

    pub fn free<S>(self, source: S) -> (GclkToken<G>, S::Dec)
    where
        S: GclkSource<G, Type = T> + Decrement,
    {
        (self.token, source.dec())
    }

    pub fn enable(mut self) -> Enabled<Self, U0> {
        // HW register writes
        Enabled::new(self)
    }
    // Other functions operating on a disabled `Gclk<G, T>`
}
impl<G, T> Enabled<Gclk<G, T>, U0>
where
    G: GenNum,
    T: GclkSourceMarker,
{
    fn disable(mut self) -> Gclk<G, T> {
        // HW register writes
        self.0
    }
}

Gclk::new consumes, upon construction, a GclkSource provided to it and returns it with a type of Enabled<_, N++> (as mentioned previously, specializations of Enabled implement Source based traits). Analogically, Gclk::free consumes a GclkSource passed in and returns it with a new type of Enabled<_, N-->. By design it is impossible to go below 0, because there is always less or equal amount of users than a counter value.

`Gclk0` case

Amount of users might be less than a value of a counter in case of special types like Gclk<Gen0> which always has an implicit single user -- synchronous clocking domain. Minimal amount of users for it is 1, making it impossible to disable and therefore consistent with its documented HW characteristics.

It also makes it impossible to change a configuration of a Gclk0 as a Enabled<Gclk0, _> cannot be deconstructed. Therefore, Enabled<Gclk0, U1> exposes additional methods that are usually available only for disabled Gclks.

Usage from the HAL perspective

Peripheral Y associated with Pclk<Y, _> will just consume it upon construction.
Thus, clocking tree that is relevant for HAL peripheral X is locked and has to be released step by step. It is worth noting, that only that part of clocking tree is locked so the granularity is quite fine.

V1 clocking API compatibility

In order to support v1 clocking compatible peripherals, every clock::v1::*Clock object implements a From<Pclk<_, _>> trait. Therefore, it is feasible to use existing peripheral implementations with new clocking API.

To make a migration simplier, there're going to be standalone functions returning available clocking presets that were available in v1 clocking.

Handling of default clocking system state

fn crate::clock::v2::retrieve_clocks returns a tuple of following type

(
    Enabled<Gclk0<marker::Dfll>, U1>,
    Enabled<Dfll<OpenLoop>, U1>,
    Enabled<OscUlp32k, U0>,
    Tokens,
)

which is supposed represent a default state of clocking system after reset (Chapter 13.7; p. 141). As mentioned before Gclk0 is owned by virtual single user representing CPU and synchronous clocking domain and count of 1 cannot be decreased further.

What's still missing?

References

If there's a reference to an external document with a specified page, it is implicit reference to SAM D5x/E5x Family Data Sheet (DS60001507F) in a context of thumbv7em based MCUs.
For thumbv6m-based MCU, it is a reference to SAM D21/DA1 Family Data Sheet (DS40001882F).

Related issues

Closes #114

bradleyharden · 2021-06-29T01:43:15Z

hal/src/thumbv7em/clock/v2/rtc.rs

+pub enum Output32kOn {}
+
+impl Sealed for Output32kOn {}
+impl Output32k for Output32kOn {}
+
+pub enum Output1kOn {}
+
+impl Sealed for Output1kOn {}
+impl Output1k for Output1kOn {}
+
+pub enum Output32kOff {}
+
+impl Sealed for Output32kOff {}
+impl Output32k for Output32kOff {}
+
+pub enum Output1kOff {}
+
+impl Sealed for Output1kOff {}
+impl Output1k for Output1kOff {}


I don't know the RTC well at all, so maybe I'm misunderstanding. But it seems like output on/off is not something we typically encode into the type system. Or is on/off really supposed to be enabled/disabled?

bradleyharden · 2021-06-29T01:43:47Z

hal/src/thumbv7em/clock/v2/rtc.rs

+//! This is a bit of a hack right now. I think it might be best if the RTC
+//! migrates into the `clock` module, since it's so integrated with OSC32KCTRL.


Yeah, it doesn't really conform very well to the rest of the module. But it's fine for now.

bradleyharden · 2021-06-29T01:45:30Z

hal/src/thumbv7em/clock/v2/xosc32k.rs

+    run_standby: bool,
+    on_demand_mode: bool,
+    start_up_masking: StartUp32k,


Here's an example. This struct grew by at least 3 bytes, because it has to store the state until the enable function.

bradleyharden · 2021-06-29T01:47:03Z

hal/src/thumbv7em/clock/v2/xosc32k.rs

+    X: Output32k,
+    Y: Output1k,


Wasn't this previously a run-time parameter, not compile-time? What's the motivation for this change? Maybe I just don't understand the Xosc32k very well?

bradleyharden · 2021-06-29T01:47:55Z

hal/src/thumbv7em/clock/v2/xosc32k.rs

-
-    /// TODO
-    #[inline]
-    pub fn set_1k_output(mut self, enabled: bool) -> Self {


Ah, maybe you can't enable both 1k and 32k output simultaneously? That would make sense to prevent at compile-time.

bradleyharden · 2021-06-29T01:56:16Z

hal/src/thumbv7em/clock/v2/presets.rs

+        $tokens:expr
+    ) => {{
+        let (gclk0, gclk5, dpll0, dfll) =
+            crate::clocking_preset_gclk0_120mhz_gclk5_2mhz!($gclk0, $dfll, $tokens);


I think you need $crate instead of crate. The former will always resolve to the crate in which it is written.

bradleyharden · 2021-06-29T01:57:05Z

hal/src/thumbv7em/clock/v2/presets.rs

+/// );
+/// ```
+#[macro_export]
+macro_rules! clocking_preset_gclk0_120mhz_gclk5_2mhz_gclk1_external_32khz {


I like the macro approach, but I hate the names. I don't know how to make them any better though, because you can't have macro namespaces. Bleh 🤮

Sympatron · 2021-11-02T14:15:04Z

Unsoundness if default state does not match the one expected after reset (BL jumping to APP case; both setup clocks) - proper solution?

Is it possible to reset all clocks? Otherwise this is quite problematic I think, because most(?) bootloaders will setup the clocks in some way.

glaeqen · 2021-11-02T14:35:51Z

Unsoundness if default state does not match the one expected after reset (BL jumping to APP case; both setup clocks) - proper solution?

Is it possible to reset all clocks? Otherwise this is quite problematic I think, because most(?) bootloaders will setup the clocks in some way.

Yes and no. Gclks expose HW register for SWRST. The rest is hit or miss. We had a conversation about this with @bradleyharden , solutions heavily depend on circumstances. If one knows a clock state before reaching retrieve_clocks, one could recreate a clock tree with types while using some unsafe without any HW writes. If one does not know the clock state before one's application starts, then it's very problematic. Solution for the former scenario is not really that bulletproof either, because, let's say, if firmware is upgraded partially, some invariants regarding clock tree expectations might get violated - in the grand scheme of things, I can imagine it's not really that hard to mess this up.

I came up with this custom ghetto solution that tries its best to restore default state in a correct order. It is impossible to restore everything to the default state, as there are some register that are populated by MCU with factory settings (like fine and coarse params for some oscillators and whatnot). In my approach I kinda ignore that and assume that user didn't mess with these too much.

//! Module containing clock system related utilities that go beyond of
//! [`atsamd_hal::clock::v2`] scope
use atsamd_hal::pac::{GCLK, MCLK, OSC32KCTRL, OSCCTRL};

/// Function implementing HW clocking reset (with some caveats).
///
/// In most cases this step is redundant. However, [`retrieve_clocks`] might be
/// unsound in scenarios when there is no full software reset between
/// application runs (eg. bootloader jumping to application or to secondary
/// bootloader). Enforcing a default state of a clocking system improves overall
/// soundness of an API.
///
/// Notes:
/// - If `Wrtlock` And Peripheral Access Controller is engaged, this procedure
///   might not be enough.
/// - Some parameters cannot be restored, eg. fine and coarse values for `Dfll`
///   running in an open mode. They are set to factory values after reset; if
///   user has changed them there is no way to restore them (is that for
///   certain?).
/// - Resetting Rtc source (to 1kHz UlpOsc32k) might corrupt Rtc operation if it
///   uses a source of different frequency AND it is supposed operate
///   continuously regardless of a switch from BL to APP/SBL.
pub unsafe fn hard_reset_clock_system(
    oscctrl: &mut OSCCTRL,
    osc32kctrl: &mut OSC32KCTRL,
    gclk: &mut GCLK,
    mclk: &mut MCLK,
) {
    // Reset main clock
    mclk.cpudiv.reset();
    mclk.ahbmask.reset();
    mclk.apbamask.reset();
    mclk.apbbmask.reset();
    mclk.apbcmask.reset();
    mclk.apbdmask.reset();
    mclk.intenclr.reset();
    mclk.intenset.reset();
    mclk.intflag.reset();

    // Reset Dfll
    oscctrl.dfllctrla.reset();
    while oscctrl.dfllsync.read().enable().bit_is_set() {}
    oscctrl.dfllctrlb.reset();
    while oscctrl.dfllsync.read().dfllctrlb().bit_is_set() {}
    //// Note:
    //// DFLLVAL contains FINE and COURSE values that come from factory
    //// If user managed to set these in previous application run, there's no easy
    //// way of resetting them
    // oscctrl.dfllval.reset();
    // while oscctrl.dfllsync.read().dfllval().bit_is_set() {}
    oscctrl.dfllmul.reset();
    while oscctrl.dfllsync.read().dfllmul().bit_is_set() {}

    // Reset Gclks and Pclks
    gclk.ctrla.write(|w| w.swrst().set_bit());
    while gclk.ctrla.read().swrst().bit_is_set() || gclk.syncbusy.read().swrst().bit_is_set() {}

    // Reset Dplls
    oscctrl.dpll.iter().for_each(|dpll| {
        dpll.dpllctrla.reset();
        while dpll.dpllsyncbusy.read().enable().bit_is_set() {}
        dpll.dpllratio.reset();
        while dpll.dpllsyncbusy.read().dpllratio().bit_is_set() {}
        dpll.dpllctrlb.reset();
    });

    // Reset Xoscs
    oscctrl.xoscctrl.iter().for_each(|xosc| {
        xosc.reset();
    });

    // Interrupts and miscellaneous
    oscctrl.evctrl.reset();
    oscctrl.intenclr.reset();
    oscctrl.intenset.reset();
    oscctrl.intflag.reset();

    // Reset Xosc32ks
    osc32kctrl.xosc32k.reset();
    // Cannot just reset, CALIB[5:0] is non zero
    osc32kctrl
        .osculp32k
        .write(|w| w.en1k().set_bit().en32k().set_bit());
    osc32kctrl.evctrl.reset();
    osc32kctrl.cfdctrl.reset();
    osc32kctrl.rtcctrl.reset();
    osc32kctrl.intenclr.reset();
    osc32kctrl.intenset.reset();
    osc32kctrl.intflag.reset();
}

Not sure if we want something like this in a HAL though. Maybe you or others have better idea how to tackle this. Probably the best option would be to introduce this dynamic clock layer to equation (DynPin like mechanism) that would allow switching back and forth from typed clocking API to runtime one. And retrieve_clock could also have a more dynamic sibling that would actually retrieve a clock state from HW. At least user could choose. BUT, I think, this is orthogonal to this PR, and could be introduced at any point in time later by people interested in developing it. @bradleyharden mentioned that he might at some point play with it and develop something like this.

Invert the way instances of `GclkOut` are created. Create them by feeding a `Pin` to an `EnabledGclk` rather than using `GclkOut::enable`.

- Store the `Pin` for the GCLK_IN case and remove `unsafe` conjuring - Consolidate into a `Settings` struct and minimize the number of register writes during configuration

bradleyharden · 2022-12-26T15:43:53Z

My only question so far is regarding how we want to roll this out. Do we still want to make v1 available and mark it as deprecated? Do we want to remove it on the next breaking semver bump? Or do we want to remove immediately? Or never remove it?

For the moment, I don't think we should do anything other than merge v2. No other parts of the HAL make use of it, so it definitely doesn't make sense to deprecate or remove v1 yet. Over time, we can migrate parts of the HAL to accept the v2 types. At that point, we can deprecate v1 and consider removing it in the future.

I'd also like to see this ported to thumbv6m chips, how much work would that realistically be? I think it's better suited for a later PR though.

Agreed. Before we deprecate or remove anything, I think we need to port it to thumbv6m. I have no idea how much work that would be, though. I haven't looked at the datasheet in any depth.

bradleyharden · 2022-12-26T16:13:17Z

It has been over two years since my initial issue and over a year and a half since @glaeqen's issue. Moreover, this PR has been open for well over a year, and several people are working directly from this branch (including myself, @glaeqen, @sakian and probably others).

With two maintainer approvals and a green CI, I think it's time we finally merged.

🚀

glaeqen · 2022-12-26T16:15:56Z

Shout out to @AfoHT aka @vcchtjader as well, considering his invaluable contribution at multiple stages of this PR. Great job everyone!

glaeqen · 2022-12-26T16:18:31Z

I think we are doing a squash merge, right? That means we should have a reasonable commit message.

bradleyharden · 2022-12-26T16:18:53Z

I'm writing it as we speak.

Add a new API for the `clock` module on `thumbv7em` targets Add a new `clock` module API that enforces correctness by construction. It is impossible to create an invalid clock tree without using `unsafe`. Specifically, use typed tokens and clocks to guarantee memory safety and act as proof that a clock is correctly configured, and use type-level numbers to count consumer clocks at compile-time and restrict a given clock's API while it is in use. This commit comes after two years of work, starting with #272, then with #429 and culminating with PR #450. Co-authored-by: Bradley Harden <[email protected]> Co-authored-by: Gabriel Górski <[email protected]> Co-authored-by: Henrik Tjäder <[email protected]>

jbeaurivage mentioned this pull request Jun 9, 2021

v0.13 Roadmap #448

Closed

8 tasks

vcchtjader force-pushed the clocking-api-v2 branch from 5866efb to f40598a Compare June 11, 2021 07:07

bradleyharden mentioned this pull request Jun 14, 2021

Questions about a proposed refactoring of the clock module #272

Closed

glaeqen force-pushed the clocking-api-v2 branch from d77a264 to 9eddde5 Compare June 14, 2021 12:28

bradleyharden mentioned this pull request Jun 14, 2021

Utilizing configure_gclk_divider_and_source and GENA enums its possible for multiple parties to attempt to take the same clock #114

Closed

glaeqen force-pushed the clocking-api-v2 branch from 401fb8d to 2209bc6 Compare June 16, 2021 13:57

bradleyharden reviewed Jun 29, 2021

View reviewed changes

glaeqen force-pushed the clocking-api-v2 branch 3 times, most recently from a3fdfea to 07b1883 Compare July 12, 2021 17:13

glaeqen force-pushed the clocking-api-v2 branch from 4c75bb4 to bba8a6c Compare July 27, 2021 15:17

glaeqen force-pushed the clocking-api-v2 branch 3 times, most recently from 04cb9a4 to 3673837 Compare September 9, 2021 15:21

vcchtjader force-pushed the clocking-api-v2 branch 4 times, most recently from 4d24a74 to 64242d2 Compare September 29, 2021 14:21

vcchtjader force-pushed the clocking-api-v2 branch from 1ac02fa to bddd31f Compare October 11, 2021 14:38

glaeqen marked this pull request as ready for review October 11, 2021 17:19

bradleyharden mentioned this pull request Oct 22, 2021

Clarify documentation of UART #527

Closed

glaeqen force-pushed the clocking-api-v2 branch from ff8fa93 to 447f5db Compare November 2, 2021 14:06

bradleyharden and others added 14 commits December 24, 2022 18:58

gclk: Refactor GclkOut

acaa968

Invert the way instances of `GclkOut` are created. Create them by feeding a `Pin` to an `EnabledGclk` rather than using `GclkOut::enable`.

dpll: Reduce naming ambiguity

29b5864

gclk: Refactor gclk to store pins and consolidate settings

d0a7e15

- Store the `Pin` for the GCLK_IN case and remove `unsafe` conjuring - Consolidate into a `Settings` struct and minimize the number of register writes during configuration

dfll: Add complete example to docs

25de379

rtcosc: Add rtcosc documentation

94a0dff

Fix feather_m4 example

950f72e

dfll: Change how to reconfigure an EnabledDfll

054a9ef

clock/v2: Fix broken documentation link

6826985

dfll: Attempt to refactor EnabledDfll::reconfigure

45e98d4

dfll: Further refactor to improve EnabledDfll::into_mode

f2c9507

Remove macro in dpll and improve naming consistency

b0f03ae

dfll: Update documentation

396bc5e

clock/v2: Fix formatting

f6eddd6

Bump MSRV because of GATs used

5f3caa5

glaeqen force-pushed the clocking-api-v2 branch from 852801e to 5f3caa5 Compare December 24, 2022 18:00

clock/v2: Remove dead code and unnecessary allow attributes

ccd47cb

bradleyharden merged commit a442991 into atsamd-rs:master Dec 26, 2022

bradleyharden mentioned this pull request Dec 26, 2022

RFC: New clocking API #429

Closed

glaeqen deleted the clocking-api-v2 branch December 26, 2022 22:41

bradleyharden mentioned this pull request Dec 27, 2022

Remove const_err lint #650

Closed

This was referenced Jan 5, 2023

Add support for SAMC2x ? #659

Open

Spi implementation relies on fragile timing #657

Closed

Add PAC for ATSAML22J18A #663

Draft

bradleyharden mentioned this pull request Jan 26, 2023

hal::sercom::uart::Config could potentially check for the correct sercom clock #668

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clocking API V2 (for thumbv7em) #450

Clocking API V2 (for thumbv7em) #450

glaeqen commented Jun 9, 2021 •

edited

Loading

bradleyharden Jun 29, 2021

bradleyharden Jun 29, 2021

bradleyharden Jun 29, 2021

bradleyharden Jun 29, 2021

bradleyharden Jun 29, 2021

bradleyharden Jun 29, 2021

bradleyharden Jun 29, 2021

Sympatron commented Nov 2, 2021

glaeqen commented Nov 2, 2021 •

edited

Loading

bradleyharden commented Dec 26, 2022

bradleyharden commented Dec 26, 2022

glaeqen commented Dec 26, 2022 •

edited

Loading

glaeqen commented Dec 26, 2022

bradleyharden commented Dec 26, 2022

		//! This is a bit of a hack right now. I think it might be best if the RTC
		//! migrates into the `clock` module, since it's so integrated with OSC32KCTRL.

Clocking API V2 (for thumbv7em) #450

Clocking API V2 (for thumbv7em) #450

Conversation

glaeqen commented Jun 9, 2021 • edited Loading

Summary

Motivation

Detailed design

Introduction

Mapping HW model to Rust

Enabled type and its helper types/traits

SourceMarker trait and its subtraits

Source trait and its subtraits

*Token types

Source/SourceMarker traits usage in an API

Gclk0 case

Usage from the HAL perspective

V1 clocking API compatibility

Handling of default clocking system state

What's still missing?

References

Related issues

bradleyharden Jun 29, 2021

Choose a reason for hiding this comment

bradleyharden Jun 29, 2021

Choose a reason for hiding this comment

bradleyharden Jun 29, 2021

Choose a reason for hiding this comment

bradleyharden Jun 29, 2021

Choose a reason for hiding this comment

bradleyharden Jun 29, 2021

Choose a reason for hiding this comment

bradleyharden Jun 29, 2021

Choose a reason for hiding this comment

bradleyharden Jun 29, 2021

Choose a reason for hiding this comment

Sympatron commented Nov 2, 2021

glaeqen commented Nov 2, 2021 • edited Loading

bradleyharden commented Dec 26, 2022

bradleyharden commented Dec 26, 2022

glaeqen commented Dec 26, 2022 • edited Loading

glaeqen commented Dec 26, 2022

bradleyharden commented Dec 26, 2022

glaeqen commented Jun 9, 2021 •

edited

Loading

`Enabled` type and its helper types/traits

`SourceMarker` trait and its subtraits

`Source` trait and its subtraits

`*Token` types

`Source/SourceMarker` traits usage in an API

`Gclk0` case

glaeqen commented Nov 2, 2021 •

edited

Loading

glaeqen commented Dec 26, 2022 •

edited

Loading