Currently I am reading through the Arm based ATSAM4L series datasheet, and in the sections BSCIF and SCIF I have encountered at least 8 different oscillators/clocks (see image below). I understand that an oscillator is necessary for a clock signal for the MCU, but why are so many different sources necessary for this MCU family and MCU's in general?

EDIT: And what are the functions of these specific oscillators?

enter image description here

enter image description here

  • \$\begingroup\$ It is one oscillator with features. May be two, but second does not have so many features. It is all about flexibility, designer choose desired configuration. \$\endgroup\$
    – user263983
    Jan 15, 2021 at 14:23

6 Answers 6


32kHz ultra low power oscillator: Used for RTCs (Real-time-clock). These can run in the background and enable time-keeping, even when the controller core is sleeping. This enables to have a running clock without the high power consumption of the controller core. The 32kHz oscillators are pretty precise and typically have an error of less than a minute per month.

32kHz RC oscillator: Similar to the above, but way less precise. RC oscillators can easily be integrated into the µC itself and don't require external parts, but have not very good tolerances. The low clock speed still enables some background stuff going on, while most of the controller is sleeping to safe power.

1MHz RC oscillator: A lot faster than the 32kHz oscillator (obviously) and enables to do some faster processing. Used for normal operation in non-sleep mode and is integrated in the controller. So for this RC oscillator no external parts are needed (again). Clock is not very precise and can vary by several percent (although often it is possible to calibrate these).

Crystal oscillator up to 30MHz: An external 30MHz crystal can speed up operation by a factor of 30 in comparison to the internal 1MHz oscillator and can be pretty precise, but needs the additional external parts. The higher clock also increases power consumption.

PLL: Enables the controller to run of a precise crystal frequency and derive an even higher clock frequency, if that is needed.

It is up to the developer to choose which clock source is the best compromise of cost, power consumption, board area, precision and performance (Which is not necessarily a static decision: The controller might run a few seconds on the high clock speed to do some acquisitions, calucations, data transfers, etc. After that it might go to deep sleep mode and only the RTC is running in the background, until some event (either by the RTC or some external trigger) wake the controler up to repeat the cycle.

  • 2
    \$\begingroup\$ Note that the because the RC oscillators need no external components, they are reliably present. I believe on this chip the 32 kHz oscillator clocks the CPU on power-up. The initialization code can then configure the clock machinery as needed to use whatever external crystals and oscillators are present. \$\endgroup\$
    – John Doty
    Jan 15, 2021 at 22:40
  • 10
    \$\begingroup\$ RC oscillators also start up much faster than crystal oscillators - an RC oscillator is usually stable and usable as clock source within one to six cycles, whereas a crystal oscillator may need several thousand cycles to stabilize. If you just want to "wakeup, run a few instructions, sleep", then the waiting time for the crystal to stabilize may be much longer than the actual processor execution time, resulting in longer wake-time and higher power consumption than with an RC oscillator. \$\endgroup\$
    – DSVF
    Jan 16, 2021 at 10:56
  • \$\begingroup\$ "not necessarily a static decision" - and not necessarily an exclusive one, for different peripherals might be independent in their clock sources. \$\endgroup\$
    – Bergi
    Jan 16, 2021 at 15:45

What these are for:

  • 32kHz low power: "digital watch" crystal. Use this when you want to power down the main oscillator but not lose track of what time it is so you can wake up periodically.

  • 32kHz RC: cheaper (no crystal), but less accurate. When you want a digital watch that doesn't tell the correct time.

  • external fast crystal: for things like USB where you need a precise high-speed frequency.

  • fast RC 80MHz: for providing the main system clock cheaply when precision is not required.

  • RC 4/8/12MHz: low-speed (therefore probably lower-power) version of the above, may be useful for clocking peripherals as well

  • DFLL/PLL: for generating faster frequencies than the available range of crystals.

  • 5
    \$\begingroup\$ (More realistically, the 32kHz RC is probably for a low-power mode where you don't care about precise timing) \$\endgroup\$
    – user253751
    Jan 16, 2021 at 9:42
  • \$\begingroup\$ PLLs are also good for generating frequencies which aren't an exact fraction of the crystal frequency. Not necessarily larger or smaller, just different. \$\endgroup\$
    – Graham
    Jan 16, 2021 at 22:22

They are not strictly necessary but the vendor is attempting to cover as many use-cases with one part as they can.

Some applications may want to use the internal oscillator, others may need a precise clock source, others may want low power consumption.

Generally you will use only one in a specific design although in some cases the clock mode is changed dynamically by the application software.

I think you will find that most of the parts in the same class as the ATSAM will have similar clock and other peripheral features. Yes, it can seem intimidating at first since there are what seem to be a bewildering array of options but often you will only need to concern yourself with one or two of them. In many cases the default will work to get you started.


Here is the clock configuration in block-diagram form from ST's configuration tool (STM32F103).

enter image description here

As you can see, there are internal oscillators and two oscillators that use external frequency-determining components (crystals or resonators typically). I have this configured to use an external 8MHz crystal and a 32.768 kHz watch crystal. I could have used the internal RC 40kHz and 8MHz oscillators, however the USB would not be reliable and the real-time clock would not be very useful ( USB requires a +/-0.25% accuracy to be within spec and the internal oscillators are more like 1-2%).

The internal oscillators are okay if you don't care too much about accuracy (but that's unacceptable for some applications). Low frequency oscillators are for saving power without going into full sleep (you can gear up to full speed clock when required) and (when accurate) for real-time clock purposes. The various dividers and PLLs help allow you to generate the various clocks required by the various internal blocks as shown. A PLL (Phase-Locked Loop) is another internal oscillator with a divider feedback loop that locks onto a multiple of the input frequency.

The ARM architecture allows you to clock the peripheral buses (APB1/APB2) at various rates to trade off power vs. performance. As well as the AHB bus, the core and so on, the ADC requires a clock. The timers require clocks. The USB peripheral requires a clock. The WDT requires an clock, preferably an independent one. And those clock speeds may change dynamically in some cases.


The ATSAM family controllers typically have one really slow 32kHz oscillator used for low power applications, either with internal RC oscillator or external quartz crystal. And one high speed internal RC oscillator for "fast as it goes".

In addition you can tweak around with PLL's, clock dividers and so on, and of course also provide external quartz. They have a ridiculously flexible clock system where you can set up a number of generic clocks and chose which ones that clock which hardware peripheral.

The purpose of all this is just to provide flexibility. It doesn't cost them much in silicon area and transistors to provide all these options. Microcontrollers have been providing complex and flexible clock options for decades now, it seems they only get more and more flexible. Which isn't always a good thing, because getting the system clock up and running, with correct flash wait states and all, is usually one of the more time consuming parts when starting up with a new MCU.


Everyone else has the facts (low power applications etc) but the motivation is reduced chip count. SoC (system on chip) is used in commodity devices for which the dominant constraints are

  • size
  • battery life
  • low part count

Such devices need often need many or all of the capabilities mentioned in other answer. Getting all of these features - especially processor control for the clocking of systems - from one integrated package would be make that package so much more desirable than less capable competitors that all of them do it. Lower part count, simpler boards, fewer failure points.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.