SpenceKonde
commented
4 years ago Per datasheet, these parts do not support external high frequency crystal. Only a 32KHz watch crystal, or an external CLOCK source. In the case of the former - like, sure it could be done, but you lose all timekeeping functions (for obvious reasons), and I can't imagine there is very much interest in that speed among Arduino people - a much more realistic use case (and one which is at the top of my priority list after I finish all the super-urgent things, which I am months behind on) is an investigation of what people are missing when they report high sleep state power consumption on these parts, and also leverage the realtime clock and the hooks I added in 2.0.0 to enable a library to stop, set, and restart millis, to offer a wrapper around the sleep functions which will stop millis timing, enable the RTC with external crystal or 32KULP and an interrupt to wake on that overflowing, but if that is what wakes it, it will immediately go back to sleep, until whatever the USER configured to wake it does so, at which time it will stop the RTC, copy it's timer value, use that plus cumulative overflows of RTC since it went to sleep as well as the previous millis value to set the current millis time, and hence keep time while in an extremely low power sleep. Like you know, all sorts of consumer electronics today do, without sacrificing micros while awake like the RTC millis option does (which I now regret adding because of this idea). Adding support for an external crystal is a low priority new feature that has been planned for some time. The main problem with it, though, is as soon as you offer an external clock source, you are no longer tied to the frequencies that the internal oscillator can use (hey, how about 12MHz, that's popular?) Okay, but that requires an implementation of micros for TCA, TCB, AND TCD! Why is there a specific implementation? If you can't divide 64 by the speed in MHz (us/clock cycle) evenly (ie. at compiletime), micros will be wrong, and jump around every millis rollover... You can just FORGET about doing floating point division - or ANY division of a long - in a time sensitive function like micros (on ATTinyCore when I realized this, someone had complainted that micros() was way wrong at certain speeds. So then I fixed it, and someone else complained that it was taking ~100us to return. And then I wrote specific bitshift implementations to approximate the division for every supported crystal speed that's not a power of two.) But yeah, my point there is that supporting an external clock source opens a real can of worms in terms of development effort, when I currently have a ton of new issues here I haven't even triaged, a new core that I promised people two weeks ago, and a whole bunch of other cool stuff in the works that will be much bigger impact.
The internal oscillator on these parts is actually pretty good, especially with the ~3v and ~5v oscillator adjustments for UART baud rates and the fractional baud rate generator (which makes all those wacky UART frequencies unnecessary). Heck, if people want the main timebase more accurate, at some point I will probably implement a thing to tune the internal HF oscillator from an external watch crystal connected to the RTC, like the new DA-series parts can do automatically.
avandalen
Hi Spence
Can you add the option to use a crystal instead of the internal RC oscillator?