I just succeeded in programming an ATtiny13 using the ArduinoISP sketch and core13 files! Yay!!
But I noticed that the Tiny started running its program rightaway after being programmed, while still being attached to the Arduino.
Isn't this dangerous? What would happen if one pin on the Arduino output LOW and one of the Tiny output HIGH at the same time, while being connected to each other? Wouldn't it cause a short, possibly destroying both chips?
So I went and looked at the code for ArduinoISP. I noticed that it pulls all four connected pins to INPUT right at the end of programming mode (line 270) and that's good. (Maybe RESET could have been left HIGH, so as not to leave the slave board reset pin floating?)
But it seems to me at the beginning of programming mode it's not as careful (line 257):
pinMode(RESET, OUTPUT);
digitalWrite(RESET, HIGH);
pinMode(SCK, OUTPUT);
digitalWrite(SCK, LOW);
delay(50);
digitalWrite(RESET, LOW);
If I'm reading this right, there is a time frame of 50 ms where the SCK pin is in OUTPUT LOW, but RESET is still HIGH (which I believe means not to reset). So if the Tiny program, for whatever reason, was outputting HIGH on its general purpose pin 2, which happens to be SCK too, wouldn't the boards make a short circuit?
whatfireflies:
I just succeeded in programming an ATtiny13 using the ArduinoISP sketch and core13 files! Yay!!
Congratulations!
But I noticed that the Tiny started running its program rightaway after being programmed, while still being attached to the Arduino.
I don't recall a problem going from programming to running. There is a potential problem going from running to programming...
http://code.google.com/p/mega-isp/issues/detail?id=22
Isn't this dangerous? What would happen if one pin on the Arduino output LOW and one of the Tiny output HIGH at the same time, while being connected to each other? Wouldn't it cause a short, possibly destroying both chips?
When idle, ArduinoISP ensures the pins are inputs with pullup disabled.
But that bug report says the same thing I said above:
If the target is driving SCK high when start_pmode is entered, this code creates a short-circuit for 50 ms. More than enough time to damage both processors.
So I have independently found the bug!
The strange thing is that my Tiny13 project was driving PB2/SCK high quite often, so the short must have certainly happened a few times. Yet the boards seem unaffected.
So I have independently found the bug!
Yup.
Yet the boards seem unaffected.
The problem is that sort of damage may not have any immediate symptoms. The life of the processor may be shortened. The ability of the pin to sink or source may have been diminished. The internal connecting wire may have partially melted.
Putting series resistors (I use 220 ohms; 1K ohms is very common) on the three SPI lines protects both sides.
And/or, Nick Gammon has published a better method for resetting the target that you could merge with the ArduinoISP sketch.
And/or, you could pressure Randall Bohn and David Mellis into fixing the problem.
And/or, I have a better method for resetting the target that you could merge with the ArduinoISP sketch.