Expand description
An external multipurpose crystal oscillator controller
An Xosc interfaces with either an external clock or external crystal
oscillator and delivers the resulting clock to the rest of the clock system.
The type parameter X is a XoscId that determines which of the two
instances this Xosc represents (Xosc0 or Xosc1). The type
parameter M represents the operating Mode, either ClockMode or
CrystalMode.
On its own, an instance of Xosc does not represent an enabled XOSC.
Instead, it must first be wrapped with Enabled, which implements
compile-time safety of the clock tree.
Because the terminal call to enable consumes the Xosc and returns an
EnabledXosc, the remaining API uses the builder pattern, where each
method takes and returns self by value, allowing them to be easily
chained.
See the module-level documentation for an example of creating,
configuring and using an Xosc.
Implementations
sourceimpl<X: XoscId> Xosc<X, ClockMode>
 
impl<X: XoscId> Xosc<X, ClockMode>
sourcepub fn from_clock(
    token: XoscToken<X>,
    xin: impl Into<XIn<X>>,
    freq: impl Into<Hertz>
) -> Self
 
pub fn from_clock(
    token: XoscToken<X>,
    xin: impl Into<XIn<X>>,
    freq: impl Into<Hertz>
) -> Self
Create an Xosc from an external clock, taking ownership of the
XIn Pin
Creating a Xosc does not modify any of the hardware registers. It
only creates a struct to track the configuration. The configuration data
is stored until the user calls enable. At that point, all of the
registers are written according to the initialization procedures
specified in the datasheet, and an EnabledXosc is returned. The
Xosc is not active or useful until that point.
sourceimpl<X: XoscId> Xosc<X, CrystalMode>
 
impl<X: XoscId> Xosc<X, CrystalMode>
sourcepub fn from_crystal(
    token: XoscToken<X>,
    xin: impl Into<XIn<X>>,
    xout: impl Into<XOut<X>>,
    freq: impl Into<Hertz>
) -> Self
 
pub fn from_crystal(
    token: XoscToken<X>,
    xin: impl Into<XIn<X>>,
    xout: impl Into<XOut<X>>,
    freq: impl Into<Hertz>
) -> Self
Create an Xosc from an external crystal oscillator, taking ownership
of the XIn and XOut Pins.
Creating a Xosc does not modify any of the hardware registers. It
only creates a struct to track the configuration. The configuration data
is stored until the user calls enable. At that point, all of the
registers are written according to the initialization procedures
specified in the datasheet, and an EnabledXosc is returned. The
Xosc is not active or useful until that point.
sourcepub fn current(self, current: CrystalCurrent) -> Self
 
pub fn current(self, current: CrystalCurrent) -> Self
Set the CrystalCurrent drive strength
sourcepub fn loop_control(self, loop_control: bool) -> Self
 
pub fn loop_control(self, loop_control: bool) -> Self
Toggle automatic loop control
If enabled, the hardware will automatically adjust the oscillator amplitude. In most cases, this will lower power consumption.
sourcepub fn low_buf_gain(self, low_buf_gain: bool) -> Self
 
pub fn low_buf_gain(self, low_buf_gain: bool) -> Self
Modify the oscillator amplitude when automatic loop control is enabled
The datasheet name for this setting is very misleading. When automatic
loop control is enabled, setting the LOWBUFGAIN field to 1 will
increase the oscillator amplitude by a factor of appoximately 2. This
can help solve stability issues.
sourceimpl<X, M> Xosc<X, M>where
    X: XoscId,
    M: Mode,
 
impl<X, M> Xosc<X, M>where
    X: XoscId,
    M: Mode,
sourcepub fn start_up_delay(self, delay: StartUpDelay) -> Self
 
pub fn start_up_delay(self, delay: StartUpDelay) -> Self
sourcepub fn run_standby(self, run_standby: bool) -> Self
 
pub fn run_standby(self, run_standby: bool) -> Self
Control the Xosc behavior in Standby sleep mode
When RUNSTDBY is disabled, the Xosc will never run in Standby
sleep mode unless ONDEMAND is enabled and the Xosc is requested by a
peripheral. When RUNSTDBY is enabled, the Xosc will run in Standby
sleep mode, but it can still be disabled if ONDEMAND is enabled and
the Xosc is not requested.
sourcepub fn enable(self) -> EnabledXosc<X, M>
 
pub fn enable(self) -> EnabledXosc<X, M>
Enable the Xosc, so that it can be used as a clock Source
As mentioned when creating a new Xosc, no hardware registers are
actually modified until this call. Rather, the desired configuration is
stored internally, and the Xosc is initialized and configured here
according to the datasheet.
The returned value is an EnabledXosc that can be used as a clock
Source for other clocks.