Using the Attiny’s Reset Pin without setting Fuse Bits

attiny13_reset The Attiny 13, 25, 45, 85 are charming little chips that as the name says it, are tiny. They are supposed to have 6 I/O pins but  pin number one  (PB5/ADC0) doubles as RESET pin and in order to use it as an I/O pin, one needs to set the proper fuses in the chip. That is not so difficult but the problem is that once that fuse is set, the chip cannot be reprogrammed  by SPI, but needs a High Voltage Programmer that first needs to reset  the specific fusebit again.
Though it was a bit unclear to me what the required Low Voltage is that the Reset pin needs for a Reset, it seems that it is lower than what is  generally interpreted as a ‘LOW’.
That potentially opens possibilities to use the range in between +Vcc and Vreset for input, without resetting the chip
To test this I used an Attiny13, hooked up an LED  and resistor to PB0 and connected the middle contact of a 25k variable resistor to Pin 1 and the outer contacts to Vcc and 0V respectively.
I then loaded the Attiny with the following program:

// Using the Reset pin as ADC0

const int Led = 0;
int x=0;
void setup() {
pinMode(Led, OUTPUT);

void loop() {

When the variable resistor is turned all the way up to the +Vcc rail, the LED flashes in a steady rhythm. When I turned down the variable resistor, the flashing frequency went up, i.e. a faster flashing LED.. as expected. This went on till the LED suddenly stopt flashing (as the RESET function kicked in).
It turns out that the point of reset was at  9K Ohm. Which is equal to 5 *(9/25)= 45/25=9/5=2.2 Volt.
That is generally not much different from what is considered a LOW and it is a bit higher than what I understood the Vreset to be.

As ofcourse you cant have a circuit  that is always on the brink of resetting, we need to build in some form of protection: something that keeps the voltage on pin 1 from hitting 2.2 Volt.
attiny13_reset2Let’s consider the following circuit. Suppose that the lowest resistance we  measure under the light circumstances we are  using is 1k. Then we know that the current through that 1 k must be minimally 2.2 mA to stay above the Reset voltage. Hence the total resistance of the LDR + the  Resistor must be  5/2.2=2.27k, hence the resistor must be not more than 1.27k. The closest E12 values are 1.2 k and 1.5 k and we should choose 1.2k to be safe.

Of course one can use the circuit with the resistor and LDR interchanged, but then  it is much harder to calculate a safe resistor as in darkness the value of the LDR may go up to several Mega Ohm, calling for a resistor that is in that same range.

Given the fact that the Reset level  is on 2.2 Volt, I have not bothered to try if it would work with digitalRead


8 thoughts on “Using the Attiny’s Reset Pin without setting Fuse Bits”

  1. Well, I don’t want to be an pain-in-the-behind, and drumming the same drum, but the digispark bootloader does exactly that: programming the ’85 with the reset pin disabled. Of course you still need a pin to indicate on boot that it should go in download mode, but the fun thing is, as soon as it loads your code, that pin is availabe again.

  2. Yes, got that. No worries, no pain in the but, but it is just that I just have too much stuff going on to throw myself on the digispark. Also, that doesnt work on the 13 🙂
    I just needed an extra pin to measure light levels and this seemed to be the easiest :-)_

  3. I have some more experience with the digispark and I am not sold on it yet. Initially all worked fine but later it suddenly didnt want to recognize the spark anymore. Fixed that, only to find out I had now new error messages when I wanted to compile for the attiny85 (Mellis or Tinycore). Seemed somehow my platform.txt got screwed up

    1. When i received the Digispark, I just followed the regular instructions and that worked fine. But when after a while i wanted to use the board again, it wouldnt work: The error i got was “Board digispark-tiny (platform avr, package digistump) is unknown”, eventhough the last time i used it everything was OK. Supposedly it can happen when you install and remove boards from the board manager without restarting. I dont recall doing that though, but ob
      Tried a lot but eventually The solution was to remove this folder:
      Then reinstall the boards from Digistump with the board manager.
      Then it worked again. However, subsequently I noticed my Tiny core gave compilation errors, which seemed to point to a platform.txt problem. Gave finding out what was wrong and reinstalled the arduino ide.
      So it is working again and the Digispark is certainly interesting and handy but during my search for a solution I noticed many people having problems with it.
      Anyway, I do like a challenge but I think I will stick to the current bootloader for a while. I had seen that link before. Great work indeed. I may do that in the future but first play with it in its current shape and form. I can tolerate the waiting time for the time being

  4. Some more thoughts on that 🙂 You have to realize that the Digispark DOES have a bootloader, so there is less available space. I am not sure how much you loose, but from memory I think it’s something like 700 bytes. What you gain is not needing your programmer (plus the additional HV tinkering if you use PB5), and a working USB interface! What you loose is that precious memory. If you don’t mind the “lets wait x seconds because I might get programmed after a reset”, you can use the standard firmware. If you do mind the wait, you need to design your hardware that at boot time you can pull PB0 to ground at boot time to initiate that wait.

    Digispark, imho, is a fantastic platform to quickly develop ATtiny85 programs. No reseating the chip and all. Or if you need some USB capabilties. I made one of those nasty fake mice that emulate a keyboard and types something like ALT – R(un) – and then some funny (or nasty!) web link 😛

    1. Yes, I fully agree. Dont get my earlier ‘hesitation’ too serious. It sure is a fantastic and quick development platform, which i realised again when i was developing the software for my capacitive probe: programming, pulling it out of the programmer, pushing it in my breadboard, trying, taking it out again, back to the programmer etc…. thats why I reverted to the digispark… and then got sidetracked coz of it not being recognized anymore but once that was solved it truly is fast.
      I regret that it isnt added to codebender. I understand that there have been talks between Digispark and codebender but that they couldnt agree on the terms/businessmodel.
      The USB part of Digispark is indeed great. I know there was a VUSB implementation available for the 85 but never got around to get into that, so yes all in all I am happier now with the digispark than 1-2 days ago 🙂

      Actually The Digispark when bought in China is also extremely cheap. I think I paid 1.15 euro, which is very close to the price of a bare DIP-8 attiny85

      Speaking of attiny, atmel has two new attiny’ s coming out in May. the Attiny102 and attiny104 that look promising even though I think only 1 resp 2k memory. Supposedly there is (in May I guess) a development board for abt 4 USD that I may have a look at.

      I am happy you can comment again. Not sure what went wrong the last time.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: