The ATtiny85 delivers 8 KB Flash, 512 bytes SRAM, and six usable GPIO pins in an 8-pin package, making it practical for cost-sensitive designs where board space is limited and a full-featured microcontroller would be overkill. It runs on 1.8-5.5 V, includes a 10-bit ADC with four channels, and supports software-driven serial communication through its Universal Serial Interface. Below I'll walk through its pinout, internal architecture, programming workflow, and the trade-offs that matter when you actually build with it.
Key Takeaways:
- Six GPIO pins share ADC, PWM, and serial functions; careful pin assignment prevents resource conflicts in real layouts.
- The RESET pin can be reconfigured as GPIO via fuses, but doing so locks you into high-voltage programming - plan your debug and production workflows before committing.
- USI requires manual bit-banging for I²C and SPI; it works for low-speed peripherals but adds firmware complexity compared to hardware peripherals.
- ADC stability depends on power supply quality and grounding; the ADC Noise Reduction sleep mode measurably improves results when baseline noise is present.
- GPIO pins source/sink 40 mA absolute maximum per the datasheet, but sustained operation above 20 mA per pin accelerates degradation - always buffer high-current loads externally.
Technical Specifications
| Parameter | Value |
|---|---|
| CPU | 8-bit AVR RISC |
| Operating Voltage | 1.8-5.5 V |
| Flash Memory | 8 KB |
| SRAM | 512 bytes |
| EEPROM | 512 bytes |
| GPIO Pins | 6 |
| ADC | 10-bit, 4 channels |
| Timers | Two 8-bit |
| Clock Speed | Up to 20 MHz (external), 8 MHz (internal RC, default) |
| Packages | PDIP-8, SOIC-8, TSSOP-8, QFN/MLF-20 |
| Temperature Range | -40 to +125 °C |
| Serial Interface | USI (software-configurable for SPI or I²C) |
| Brown-Out Detection | Yes |
| Watchdog Timer | Yes |
Pin Configuration
| Pin | Primary Function | Alternate Functions |
|---|---|---|
| 1 | PB5 (RESET) | PCINT5, ADC0, dW (debugWIRE) |
| 2 | PB3 | PCINT3, XTAL1, CLKI, ADC3 |
| 3 | PB4 | PCINT4, XTAL2, CLKO, ADC2 |
| 4 | GND | Ground |
| 5 | PB0 | MOSI, DI, SDA, AIN0, OC0A, AREF, PCINT0 |
| 6 | PB1 | MISO, DO, AIN1, OC0B, OC1A, PCINT1 |
| 7 | PB2 | SCK, USCK, SCL, ADC1, T0, INT0, PCINT2 |
| 8 | VCC | Power supply |
Every GPIO pin multiplexes at least three functions. From experience, the most common conflict is between SPI programming (which uses PB0, PB1, PB2) and application peripherals on those same pins. If your application circuit loads those pins heavily or holds them in a fixed state, ISP programming can fail intermittently. Adding series resistors (220-470 Ω) between the ATtiny85 and external components on the SPI lines lets the programmer override the application circuit during uploads.
Pin 1 defaults to RESET with an internal pull-up. Configuring it as GPIO (PB5) through the RSTDISBL fuse gives you one extra I/O pin, but you lose the ability to reprogram via standard ISP. High-voltage parallel programming (HVPP) is then required, which needs a specialized programmer and adds complexity to production workflows. I've seen teams disable RESET to gain that sixth pin, only to discover late in the project that field updates become impractical.
Block Diagram and Internal Architecture
The ATtiny85 uses a Harvard architecture with separate 8 KB Flash for program storage and 512 bytes SRAM for runtime data. Flash endurance is rated at 10,000 write/erase cycles per page; EEPROM is rated at 100,000 cycles. If your application writes calibration data or logs frequently, you'll hit EEPROM limits faster than you expect - distribute writes across multiple addresses or switch to external storage for high-cycle-count data.
Two 8-bit timers (Timer0 and Timer1) generate PWM, count external events, and trigger interrupts. Timer0 is simpler and typically used for basic PWM or delay functions. Timer1 includes a PLL mode that can generate high-frequency PWM (up to 64 MHz on PB1/PB4 with 5 V supply), which is useful for applications like IR carrier generation or high-frequency dimming.
The watchdog timer can reset the chip if the firmware hangs, but it also operates as a low-power interval timer in sleep modes. In one battery-powered design, we used the watchdog to wake the ATtiny85 every 8 seconds, measure a sensor, and return to sleep - resulting in average current draw below 10 µA.
Power Supply and Clock Configuration
The ATtiny85 ships with fuses set for the internal 8 MHz RC oscillator divided by 8, giving an actual 1 MHz clock. This conservative default works across the full voltage range but leaves performance on the table. For 5 V operation, reconfiguring fuses to run the internal oscillator at full 8 MHz is straightforward and doesn't require external components.
When you need precise timing - say, for a UART at standard baud rates or a frequency counter - the internal oscillator's ±10% factory calibration isn't tight enough. An external 16 MHz or 20 MHz crystal improves accuracy to ±50 ppm but adds two capacitors and occupies PB3/PB4. That trade-off is worth it for communication-heavy applications, but painful if you're already pin-constrained.
Brown-out detection (BOD) prevents the CPU from executing invalid instructions when supply voltage sags. Enabling BOD at 2.7 V or 4.3 V adds roughly 20-25 µA to sleep current. For battery designs targeting sub-microamp sleep, you may need to disable BOD and handle low-voltage conditions in firmware - accepting the risk of occasional glitches during power-down.
GPIO Characteristics and Load Limits
Each GPIO pin can source or sink up to 40 mA absolute maximum according to Microchip's datasheet, but that's a destructive limit, not an operating spec. Recommended continuous current per pin is 20 mA, and total current across all pins should stay under 200 mA to avoid internal ground bounce and latch-up risk.
Driving an LED directly from a GPIO is common in hobby projects, but the forward voltage and current need careful consideration. A standard red LED with 2 V forward drop at 20 mA on a 5 V supply needs a 150 Ω resistor minimum. I've debugged boards where someone used 47 Ω "because the LED was too dim" - it worked for a few hours, then the GPIO failed permanently.
For loads above 20 mA - motors, relays, solenoids, or even high-power LEDs - use an external MOSFET or BJT. A 2N7002 N-channel MOSFET costs pennies and switches hundreds of milliamps cleanly with a 10 kΩ gate resistor. Trying to parallel GPIO pins to increase current capacity doesn't work reliably; slight differences in pin impedance cause uneven current sharing and potential damage.
ADC Operation and Noise Management
The 10-bit ADC converts 0-VCC (or an internal 1.1 V or 2.56 V reference) into values from 0 to 1023. Resolution is 10 bits, but effective number of bits (ENOB) in a noisy environment can drop to 8 or even 7 bits if you don't address power supply noise.
Three things improve ADC stability in my experience:
- Decoupling capacitors close to the chip. A 100 nF ceramic and a 10 µF electrolytic in parallel, placed within 5 mm of VCC and GND pins, cut high-frequency switching noise.
- ADC Noise Reduction sleep mode. Halting the CPU during conversion eliminates digital switching noise inside the chip. The difference is measurable: I've seen noise floors drop from ±8 LSB to ±2 LSB just by enabling this mode.
- Separate analog ground or star grounding. If the ADC shares a return path with PWM-driven loads, ground current from the PWM injects noise into ADC measurements. Running a dedicated ground trace back to the power supply for the ADC reference improves results noticeably.
The ADC also supports differential input mode with optional gain (1×, 8×, 20×, 32×) on certain pin pairs. This is rarely documented in tutorials but works well for small differential signals like thermocouple or strain gauge bridges. Gain comes at the cost of reduced input range and increased offset error, so calibration becomes critical.
Serial Communication via USI
The Universal Serial Interface (USI) is a minimal hardware block that assists with serial protocols but leaves most of the work to firmware. It includes a shift register, a counter, and basic clock generation - enough to bit-bang I²C or SPI at low to moderate speeds.
When USI works well:
- Talking to a single I²C sensor at 100 kHz.
- Driving an SPI display or DAC where the ATtiny85 is always the master.
- Prototyping or low-volume designs where firmware complexity is acceptable.
When USI becomes a problem:
- Multi-master I²C or clock stretching scenarios; the USI doesn't handle these automatically.
- High-speed SPI above 1 MHz; timing gets difficult without dedicated hardware.
- Applications where you also need UART - there's no UART hardware, so you'll bit-bang that too, consuming CPU cycles and complicating timing.
I've used USI-based I²C libraries like TinyWireM successfully with sensors such as the BMP280 and SSD1306 OLED. But I've also spent hours debugging a case where an I²C device held SCL low (clock stretching), and the library didn't detect it, causing the firmware to hang. The lesson: test USI code against your actual peripherals early, not on the bench with ideal conditions.
Programming the ATtiny85 with Arduino IDE
Programming the ATtiny85 through the Arduino IDE requires adding a third-party board definition, such as the ATTinyCore by Spence Konde or the older attiny package from David Mellis. These cores map Arduino functions like digitalWrite() and analogRead() to the ATtiny85 hardware.
Wiring for ISP programming:
| ATtiny85 Pin | ISP Programmer Signal |
|---|---|
| 1 (RESET) | RESET |
| 5 (PB0) | MOSI |
| 6 (PB1) | MISO |
| 7 (PB2) | SCK |
| 8 (VCC) | +5V (or target voltage) |
| 4 (GND) | GND |
You can use a dedicated USBtinyISP, USBasp, or any Arduino board configured as an "Arduino as ISP." If using an Arduino as ISP, place a 10 µF capacitor between RESET and GND on the Arduino to prevent it from resetting during upload.
Board settings matter:
- Select the correct clock speed (1 MHz, 8 MHz internal, or 16 MHz external).
- Choose "Burn Bootloader" once to write the fuse settings - this step doesn't install a bootloader (the ATtiny85 doesn't use one), but it configures the fuses to match your selected clock.
- After setting fuses, upload sketches via "Sketch > Upload Using Programmer" or set the programmer as default in preferences.
Arduino pin numbers don't match physical pins directly. For example, Arduino digital pin 0 corresponds to PB0 (physical pin 5), and Arduino digital pin 2 is PB2 (physical pin 7). Check the core documentation or pinout diagram before wiring.
Minimal Working Circuit
A minimal circuit needs only:
- VCC (pin 8) connected to 3.3 V or 5 V supply.
- GND (pin 4) connected to ground.
- A 100 nF ceramic capacitor between VCC and GND, placed close to the IC.
- Optionally, a 10 kΩ pull-up resistor on RESET (pin 1) if your supply is noisy - though the internal pull-up usually suffices.
An LED with a current-limiting resistor (220-470 Ω for 5 V, 150 Ω minimum for 3.3 V) connected to PB0 (pin 5) provides visual feedback. The internal 8 MHz RC oscillator runs by default, so no external crystal is required.
This setup works reliably for blink tests, PWM experiments, and initial firmware development. For production or noise-sensitive applications, add a 10 µF bulk capacitor in parallel with the 100 nF ceramic to handle transient current demands.
Common Issues and Practical Fixes
| Problem | Root Cause | Solution |
|---|---|---|
| ISP upload fails with "device signature mismatch" | Wrong chip selected in IDE, or fuses set to external clock with no crystal present | Verify board selection; if fuses are wrong, connect an external clock signal to PB3 or use HVPP to recover |
| ADC readings drift or jump randomly | Power supply noise, missing decoupling capacitor, or poor grounding | Add 100 nF + 10 µF decoupling close to VCC/GND; enable ADC Noise Reduction mode; separate analog and digital ground paths |
| I²C/SPI communication fails intermittently | USI timing incorrect, clock speed mismatch, or external pull-ups missing (I²C) | Double-check clock selection and fuse settings; add 4.7 kΩ pull-ups to SDA/SCL for I²C; reduce bus speed in firmware |
| GPIO pin stops responding after running for hours | Pin driven beyond current limit, or exposed to voltage spike | Check LED resistor values; buffer high-current loads with MOSFET; add transient protection (diode or TVS) if pin connects to external cables |
| Code runs at wrong speed or timing is off | Clock fuse settings don't match Arduino IDE board selection | Burn bootloader (sets fuses) after changing clock setting; verify actual clock frequency with a scope or logic analyzer |
When RESET fuse is accidentally disabled:
If you set the RSTDISBL fuse and lose ISP access, standard programmers won't work. You need a high-voltage parallel programmer (HVPP) like the AVR Dragon (discontinued but available used) or open-source designs based on Arduino. This applies 12 V to the RESET pin while holding specific pins in defined states, which forces the chip into programming mode regardless of fuse settings. It's recoverable, but annoying and time-consuming.
When to Use the ATtiny85 (and When Not To)
Good fit:
- Simple control tasks: LED drivers, sensor readers, small displays.
- Space-constrained designs where an 8-pin package saves board area.
- Battery-powered applications leveraging sleep modes (down to ~0.1 µA in power-down with watchdog off).
- Cost-sensitive designs where every cent per unit matters at volume.
Poor fit:
- Applications requiring multiple serial peripherals simultaneously (UART + SPI + I²C) - firmware complexity explodes.
- High-speed communication or tight timing requirements - limited by USI and single-threaded execution.
- Projects where development speed matters more than cost; moving to an ATmega328P or STM32 gives you hardware UART, SPI, I²C, and fewer headaches.
I've used the ATtiny85 successfully in LED lighting controllers, battery monitors, and IR remote receivers. But I've also abandoned it mid-project when requirements expanded to include a UART debug port and SPI flash logging - things that are trivial on a larger chip but painful on the ATtiny85.
Conclusion
The ATtiny85 remains relevant for designs where size, cost, and power are the primary constraints and functionality stays within its well-defined limits. Its six GPIO pins with shared functions require careful pin assignment, and the software-driven USI demands more firmware effort than hardware peripherals. ADC performance depends heavily on power supply design, and GPIO current limits are real - exceed them and pins fail permanently.
Understanding fuse settings, RESET pin trade-offs, and ISP programming workflows before committing to a design prevents costly late-stage surprises. For the right application, the ATtiny85 delivers reliable control in a minimal footprint. For anything more complex, evaluate whether the firmware burden and hardware constraints outweigh the cost savings.
