Attiny85 Fuse Calculator

ATTiny85 Fuse Calculator

Calculate low, high, and extended fuse bytes for the ATTiny85 with a clean interface for clock source selection, brown-out detection, EEPROM retention, watchdog policy, and advanced programming flags. This tool is designed to help you avoid common brick scenarios while still giving you direct control over the exact fuse bytes your programmer will write.

Factory defaults supported AVRDUDE-ready output Chart visualization Bit-level clarity

Fuse Settings

Safety note: changing RSTDISBL, DWEN, or selecting an unsupported clock source can make the device appear dead over normal ISP. Double-check your hardware before programming.

Results

Choose your options and click Calculate Fuses to generate low, high, and extended fuse values, plus a ready-to-use programming command.

Expert Guide to the ATTiny85 Fuse Calculator

The ATTiny85 is one of the most widely used 8-bit AVR microcontrollers in compact embedded designs. It is inexpensive, power efficient, easy to breadboard, and capable enough for sensor nodes, LED effects, timing circuits, low-power control systems, and custom USB experiments. Yet one area consistently causes trouble for both beginners and experienced developers: fuse bytes. A fuse calculator exists to make these device configuration bits understandable, repeatable, and safe to use.

On the ATTiny85, fuse bits are not ordinary program memory. They are configuration bits stored in a special area that control hardware behavior such as the startup clock source, oscillator division, brown-out threshold, EEPROM erase behavior, watchdog policy, and a few advanced programming features. Because some of these bits are active-low, fuse planning is easy to get wrong when done mentally. That is why an ATTiny85 fuse calculator is so useful: it translates feature choices into the exact hexadecimal bytes your programming tool expects.

Why fuse bytes matter

If you write the wrong application code, you usually just reflash the microcontroller. If you write the wrong fuse bytes, you can create a device that no longer responds in your normal programming setup. This often happens in three situations. First, the reset pin is disabled, which breaks standard ISP access. Second, debugWIRE is enabled and the user forgets to cleanly exit that mode. Third, the chip is configured for an external clock source that does not exist on the actual circuit. In all three cases, the ATTiny85 may look dead even though it is not physically damaged.

Using a calculator reduces risk because it shows not only the final bytes, but also the direct implications of each choice. For practical development, that means fewer recovery sessions, fewer mysterious “programmer not responding” errors, and faster board bring-up.

Understanding low, high, and extended fuses

The ATTiny85 uses three fuse bytes that most developers care about:

  • Low fuse: mostly clock behavior, startup timing, divide-by-8 option, and clock output.
  • High fuse: reset disable, debugWIRE, SPI programming enable, watchdog policy, EEPROM preservation, and brown-out detection bits.
  • Extended fuse: self-programming related configuration.

A common point of confusion is that many AVR fuse bits are programmed when written as 0, not 1. For example, if CKDIV8 is enabled, the relevant fuse bit is cleared. The same logic applies to several other control bits. A calculator helps because it handles that inversion automatically and presents the results in plain language.

Factory default fuse set

A well-known default configuration for the ATTiny85 is:

  • Low fuse: 0x62
  • High fuse: 0xDF
  • Extended fuse: 0xFF

That default setup corresponds to the internal 8 MHz RC oscillator with the divide-by-8 fuse enabled, which gives an effective 1 MHz system clock at startup. This is one reason many new users are surprised when timing-sensitive code appears eight times slower than expected. The oscillator itself is 8 MHz, but the CPU clock is divided down unless you clear CKDIV8.

Common ATTiny85 preset Low fuse High fuse Extended fuse Effective CPU clock Typical use case
Factory default 0x62 0xDF 0xFF 1 MHz Safe default development and low-power starting point
Internal 8 MHz, no divide 0xE2 0xDF 0xFF 8 MHz General-purpose projects without external timing hardware
Internal 8 MHz, BOD at 2.7 V 0xE2 0xDD 0xFF 8 MHz Battery or regulated systems needing better brown-out safety
PLL 16 MHz, no divide 0xE3 0xDF 0xFF 16 MHz Higher-speed timing or USB-adjacent experimental work

Clock selection: the fuse setting that affects everything

The most important fuse decision is clock selection. The ATTiny85 can run from internal RC sources, a very low-frequency internal oscillator, an external clock input, or the internal PLL in supported modes. Your selection changes startup behavior, timing accuracy, power characteristics, and even whether the device can be programmed in-circuit after a fuse change.

For most projects, the internal 8 MHz RC oscillator is the best balance of simplicity and capability. It requires no external crystal or resonator and works well for general control tasks. If your code uses UART-like bit timing, software USB tricks, or narrow timing tolerances, you may need calibration, PLL mode, or a different design choice entirely. The calculator helps by making the byte math easy, but it does not replace system-level judgment about timing requirements.

One especially important setting is startup delay. A longer startup period can improve stability if the supply rises slowly or if the circuit needs time to settle. In noisy or battery-powered designs, adding startup margin can prevent intermittent boot issues that are otherwise hard to reproduce.

Brown-out detection and power integrity

Brown-out detection, often shortened to BOD, resets the microcontroller when supply voltage falls below a configured threshold. This is crucial in systems where low voltage can corrupt EEPROM writes, create unstable flash reads, or produce erratic peripheral behavior. If your ATTiny85 controls relays, writes calibration values, or manages a battery-driven output stage, BOD is often worth enabling.

The tradeoff is power consumption. Brown-out circuitry consumes additional current, so ultra-low-power sleep designs sometimes leave it disabled. The right decision depends on whether data integrity or battery life has higher priority.

BOD setting BODLEVEL bits Nominal threshold Best fit Risk if disabled
Disabled 111 No hardware brown-out reset Extreme low-power designs with tolerant firmware Unpredictable execution during voltage sag
1.8 V 110 About 1.8 V Low-voltage battery systems Limited protection if running at higher clock rates
2.7 V 101 About 2.7 V Common 3.0 V or 3.3 V embedded designs Less battery utilization near discharge end
4.3 V 100 About 4.3 V 5 V systems needing strong undervoltage protection May reset too early on marginal 5 V rails

EEPROM preservation and watchdog policy

The EESAVE fuse determines whether EEPROM is erased during a chip erase cycle. This matters when your board stores calibration constants, serial numbers, or field-updated settings. If your production workflow relies on preserving those values while refreshing firmware, enabling EEPROM retention can save time and prevent accidental data loss.

The WDTON fuse controls whether the watchdog timer is permanently enabled by hardware. Most developers leave this off and manage the watchdog in firmware instead. However, in fail-safe systems where the watchdog must never be bypassed, an always-on setting may be appropriate. Be careful: forcing watchdog behavior without planning startup and boot timing can create confusing reset loops.

Two settings most likely to brick a development board

  1. RSTDISBL: Disabling reset turns the reset pin into a normal I/O pin. That may look attractive on a small package, but it also breaks standard ISP access. Recovery usually requires high-voltage programming.
  2. DWEN: Enabling debugWIRE changes the way the reset pin behaves. If you enable it for debugging and then forget to disable it properly in your toolchain, later programming attempts can fail.

In other words, a professional ATTiny85 fuse calculator should not only produce bytes. It should also warn you when you are stepping into recovery-tool territory. That is why this calculator flags dangerous combinations in the results panel.

How to use an ATTiny85 fuse calculator correctly

  1. Select the intended clock source and startup behavior.
  2. Decide whether divide-by-8 is required.
  3. Choose a brown-out threshold that matches your supply rail and performance target.
  4. Enable EEPROM preservation only if your workflow needs it.
  5. Leave reset and debugWIRE untouched unless you fully understand the recovery path.
  6. Generate the fuse bytes and save them in your project notes.
  7. Program the device using a verified command and test the board immediately after writing fuses.

Real-world programming workflow

Many developers use AVRDUDE with a USBasp, Atmel-ICE, or another compatible programmer. A typical command generated by a calculator might look like this:

avrdude -c usbasp -p t85 -U lfuse:w:0xE2:m -U hfuse:w:0xDF:m -U efuse:w:0xFF:m

After writing new fuses, it is good practice to read them back and verify the values. On a production line, this readback step catches socketing issues and helps ensure every unit matches the intended hardware configuration.

Choosing between low power and reliability

There is no universal “best” fuse set. A coin-cell sensor node may prioritize minimum current draw and therefore disable brown-out detection, retain a low clock speed, and accept wider timing error. A motor controller running from a noisy 5 V rail may do the opposite: enable a higher BOD level, keep a robust startup delay, and use a faster system clock. Fuse calculation is therefore not just arithmetic. It is the translation of product requirements into hardware behavior.

That is also why published “best ATTiny85 fuse settings” articles can mislead people. What works perfectly for a battery LED blinker may be a bad fit for a data logger or a software-timed communications design. A good calculator plus a clear understanding of the circuit always beats a copy-pasted hex value.

Authoritative background references

If you want to deepen your understanding of timing, oscillator behavior, and AVR development contexts, these resources are useful starting points:

Final recommendations

For most ATTiny85 projects, start with the internal 8 MHz oscillator, decide whether you want the CPU to run at 1 MHz or 8 MHz, keep SPI programming enabled, leave reset functionality alone, and choose a brown-out level that matches your supply rail. If your product stores settings in EEPROM, enable retention. If your product must survive firmware hangs autonomously, evaluate the watchdog carefully before making it permanent in hardware.

An ATTiny85 fuse calculator should be treated as a configuration assistant, not just a convenience widget. The best result is not simply a valid hexadecimal number. The best result is a microcontroller that starts reliably, runs at the expected speed, protects itself during supply dips, and remains recoverable during development. Use the calculator to make those decisions explicit, document them in your project, and verify them on hardware every time you revise your board or firmware assumptions.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top