Description
This is Issue 302 moved from a Google Code project.
Added by 2010-07-22T22:03:33.000Z by drmn...@gmail.com.
Please review that bug for more context and additional comments, but update this bug.
Original labels: Type-Enhancement, Priority-Medium
Original description
What change would like to see?
This may not be possible, but if it is, include a method for the ArduinoISP sketch to determine whether or not the target AVR is being clocked. Since the Arduino IDE calls avrdude to do the actual programming and the ArduinoISP sketch emulates the stk500 bootloader protocol, this information may have to be reported back in a creative way, such as a 'special' chip signature value or other unique error status that won't break the stk500 protocol.
If this is not possible, add a link from the ArduinoISP tutorial to a basic tutorial on crystal oscillators (how to select, match crystal/capacitors, common gotchas).
Why?
For most users, their first time using ArduinoISP on a breadboarded AVR (or loading bootloaders in general) will also be their first time buying and wiring their own crystal. My experience is that crystal oscillators are kind of fiddly, and it
would be easy for a user to run into problems because their crystal
isn't starting: mismatched crystal/capacitors, too much stray
capacitance on breadboards, parasitic loads (dirty breadboard, or user
trying to check it with a scope/meter and killing oscillation in the
process)... and no easy way to determine if the crystal is starting reliably.
If the target AVR's "correctly wired but not clocked" state is distinguishable in any way from the "ISP lines miswired" state, this would be valuable diagnostic info.
Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?
No compatibility issues forseen - provided an appropriate method is used to report back the clock status.