ATTiny85 internal oscillator "consistency" - Page 1
Forum section: electronics / beginners

author: Infraviolet
author_rank: Super Contributor
timestamp: May 28, 2025, 01:22:09 am
content: I'm in the early stages of a small project which involves using a small 8 bit microcontroller (which given the one's I've had prior experience with and have to hand, will be an ATTiny85 or ATTiny84) to measure the time of some pulses, pulses coming from circuits such as LC oscillators. The actual time of the pulses is less important than spotting changes in their timing. What this means is that whilst I don't need the MCU's clock to be perfectly matched to a true 16.000000000...MHz, I do need it to stay permanently consistent (to within some margin)at whatever frequency it actually runs at. I'd like to understand what tolerance I can plausibly expect for that.The ATTiny85, and the rest of it's series, have an inbuilt PLL of some sort which lets it generate a 16MHz clock for itself, no external parts required, from it's internal 8MHz oscillator. I know that the 8MHz can be off in theory by 10%, which is fine if for a given device it is always off by the same amount. I don't know whether the PLL'ing will then tighten or worsen any such error in the 8MHz frequency either. But does anyone know how the inaccuracy might vary over time, and with variations in conditions like ambient termperature and supply voltage? I'm not after the true accuracy against perfect seconds here, nor am I concerned about the spread between different ATTiny85 chips which have rolled off the production line, I'm simply after a figure for how much (as a slightly tighter than order of magnitude figure: 10%, 5%, 1%, 0.5%, 0.1%, 0.05%, 0.01%...) the imperfect frequency that one particular device has might change over time and conditions. Does anyone know this? Though I could find notes about calibration registers to adjust the clock frequency of a specific device to be closer to true, ctrl+f ing through the datasheet for mentions of how frequency might vary over hours, days and years of time didn't find anything.The alternative would be to switch to an external oscillator, I'd also have to shift to the ATTiny84 to do this as using up two GPIO pins for a crystal and two 22pF capacitors wouldn't leave me enough pins to spare on the ATTiny85. I understand that the frequency of such a crystal will be more accurate against truly perfect time measurements, though I'm not so sure how much this might also drift over time and with voltage or temperature (or any other type of? anything else to be aware of in this regard??) conditions.Thanks

author: brucehoult
author_rank: Super Contributor
timestamp: May 28, 2025, 01:59:16 am
content: There's going to be some temperature variation, but I don't know how much. Probably extremely minimal within "room temperature" range, but maybe it'll be in a harsher environment, you haven't said.Have you checked the data sheet?I've had no problems with ATTiny85 staying synched with UARTs or WS2812 RGB LED strings, but admittedly that's been in probably 20C - 25C. Both of those have pretty loose timing requirements ... 5% or so for RS-232 and maybe 10% for WS2812 (I mean sender and receiver out by that amount in opposite directions).Btw, five years ago I was using '85s for a few things, but now I've switched to the $0.10 CH32V003 which is available in the same 8-SOIC package as the '85 (but not PDIP, sadly), or in 16 or 20 pin packages with up to 18 GPIOs. Like the '85 it doesn't need any external components, but the capabilities are more like an ATMega168 or 328 (2k RAM, 16k flash) but 32 bit and 48 MHz clock.

author: pqass
author_rank: Super Contributor
timestamp: May 28, 2025, 03:24:31 am
content: QuoteSee attached; from pages 181, 243, 244here.The graphs show variations given temperature and supply voltage but nothing about aging.

author: brucehoult
author_rank: Super Contributor
timestamp: May 28, 2025, 03:31:31 am
content: So at 5V it's within 1% from about -10C to +70C, or 0.1% from 20C to 30C.

author: Peabody
author_rank: Super Contributor
timestamp: May 28, 2025, 03:07:40 pm
content: Over what period of time will you be measuring these variations? Are you only looking at variations over a few milliseconds, or do you need to compare the current measurement with yesterday's?The internal 8MHz oscillator will vary with temperture and supply voltage, much more than a crystal, but then we don't know what consistency you actually need.If you have a GPS module with a PPS output, you could test your ATtiny85 to see how much it varies. Once the module is locked in, the PPS signal will be about as perfect a 1Hz signal as you can get. You could read the number of timer clocks between falling edges, and display the delta from the previous count. That should give you an idea of how stable it is under various conditions.In fact I think the 85 has a capture setting for its timer that lets the falling edge of the input immediately capture and store the current timer count. So it would be unaffected by whatever other code is executing, even if it's in an ISR.

author: PGPG
author_rank: Frequent Contributor
timestamp: May 28, 2025, 03:29:29 pm
content: Quote from: Infraviolet on May 28, 2025, 01:22:09 amI would assume 1% with temperature and 1% per few years. So around 2%.Quote from: Infraviolet on May 28, 2025, 01:22:09 amFirst crystal datasheet I have just found:https://www.vishay.com/docs/35064/xt35.pdfYou can order with initial tolerance from 10ppm to 30ppm and with temperature stability from 20ppm to 100ppm.So you can expect as worse case not bigger than 100ppm drift (=0.01%).

author: Infraviolet
author_rank: Super Contributor
timestamp: May 28, 2025, 05:09:58 pm
content: Thanks for the info.I can't yet give a figure as to the level of consistency I will need, I'm trying to work out initially what level of consistency I can expect, then see if this will be sufficient.The graphs with temperature are useful, across the range of room temperature but a bit either side (say 0 to 30 celsius) it's clearly within 0.5% or so.Aging though is one I'm particularly interested in. I'm not yet sure of the level of consistency I'll be aiming for, but knowing how it could change over a few years would be good. That is a few years total time, regardless of whether the duty cycle for the circuit being powered on is 100% or 5 minutes a day... The idea is that I would calibrate the circuit once as to what a typical length of pulse looks like (again what this normal length will be isn't yet decided, but probably in the range of 20us to 20ms) and then it would monitor how pulses at future times deviate (by a percentage likely in the 0.5% to 20% range... looks like I've got some idea of my needed consistency then, wouldn't need to be better than +/-0.25% in worst possible case, will definitely want tighter than +/- 5%) from the calibrated expected length.The capture method on the attiny85 is one I'm aware of, I think it applies to all ATTiny and ATMega devices too.I won't be using the CH32V003 for this, but sounds an interesting option for future projects. Being available in SOIC is nice, my favourite format for most things. What is the CH32V003 like in terms of flashing code to it, the same ICSP method as ATTiny and Atmega AVR's use? And I assume that one programs it using C code, and simply uses different functions to handle hardware functionality as compared to C code for AVR chips?

author: brucehoult
author_rank: Super Contributor
timestamp: May 29, 2025, 01:04:37 am
content: Quote from: Infraviolet on May 28, 2025, 05:09:58 pmProgramming an ATTiny85 is actually kind of crazy with 6 of the 8 pins used: GND, Vcc, clock, MISO, MOIS and also holding RESET low.CH32V003 uses a proprietary 1-wire protocol, using GND, Vcc and SWDIO (pin 8 on the 8-SOIC, which also serves as PD1 on all packages, and also PD5 and UTX on the 8 pin). As well as programming the chip it's also used for the debugger. They sell the WCHLink-E for a couple of bucks which handles the '003, the larger chips that use a 2-wire protocol, and also WCH's Arm chips. They have their own fork of OpenOCD . The 1-wire protocol spec is published and there is e.g. a project using a Pi Pico as the programmer.QuoteIt's a standard 32 bit RISC, supporting any language that the GNU Compiler Collection or LLVM support, but there are also many other languages with their own RISC-V code generators. The only wrinkle is that it uses a cut-down version of RISC-V with only 16 registers instead of 32, but that's just a matter of telling gcc or llvm "-march=rv32e -mabi=ilp32e" (in fact march=rv32ec to get smaller code).So yes, usually C or C++, maybe bits of asm. Some lunatics use Rust.WCH have their own Arduino library for it (and their bigger chips), so you can just do that if you want.The peripherals are clones of STM32. Example code for STM32 GPIOs or UART or timers or SPI or whatever pretty much Just Work, assuming they're written in C not Arm asm.Some people delight in getting as much as possible out of the 8-SOIC version of the CH32V003. E.g. Olimex's €1 "RVPC" kit which supports a PS/2 keyboard and bit-bangs VGA output with the only active component other than the CH32V003 being a transistor to drive the piezo buzzer.Our host did a quick try out 2 1/2 years ago I just learned recently that all the vendor OpenOCD forks aren't particularly vendor's laziness, but the OpenOCD maintainer not accepting patches.

author: MathWizard
author_rank: Super Contributor
timestamp: May 31, 2025, 02:23:03 am
content: So what parts and circuits inside these MCU's, go faster when the temp or voltage goes up ? I know if there's actually resistors in there, and there R drops with temp, it might decrease some RC time constant somewhere. What effect does temperature have on capacitance in mosfets?Next time I make an oscillator in LTSpice, I'll have to try changing the temperature and Vcc.So to make a basic temperature controlled box, do people ever just use a power resistor or even transistor on a heatsink, as the heater element? And then just put it in a box and have a control loop.