starting at the top-level working in a U-shape towards the top-right, number each "usable" pin sequentially.

oh lordy... all these years i thought portd was pins 1-7, portb 8-15, etc.. now i see that was coincident and the real method was far more ridiculous than i imagined. who are these guys and what are they trying to do to me?

generally there are 2 ways we program an avr. isp makes use of hardware built into the chip (miso/mosi/sck) and is normally the way to flash a raw chip from the factory. arduino chips have a bootloader program put into them which allows loading code via a serial port using the avr self program (spm) instructions. but a bootloader must be intalled using isp for this to work. so ALL chips can be isp flashed but only those with bootloader previously programmed can use a serial port. the datasheets and atmel app notes go into much more detail. google is your friend.

NOTHING allows you to change fuse w/o erasing the chip. otherwise lock bits serve no purpose at all.

actually there is no 100% way to protect. for $400-$600 pirate houses in china and malasia will cut into the chip, disable lock bits, and read out the code. another level of protection is to enable rstdsbl which prevents most users from erasing and reprogramming. but of course you no longer have access either.

yes, thats true. i was thinking of final application like mentioned in op. but like you say the guys who sell large quantities of arduino chips probably dont do one at a time. or maybe they have digikey or other atmel vendor put the bootloader in. not too expensive in quantty.

actually i was referring to isp which is easy because no responses at all are required from the chip and they are all simply wired in parallel.  its doable with serial bootload also but data from the chip is needed so not as easy and again requires custom software. but imo if you need to do many chips at once using a bootloader dont make too much sense.

ive never found verfication of any practical use whatsoever. does little more than triple flashing time. in fact its turned off in all my avrdude command lines. in my experience if you can read a fuse or signature for a given setup then unlikely to be any issues with writing flash or eeprom. it may be useful to check new programming hardware or software but even then ive found things either work or dont. for those who require peace of mind and time/productivity not so important then maybe does serve a purpose. as usual everyones mileage may vary.

op gave no hint of that. and im guessing most here in the arduino forum do have chips with a bootloader. in any case my comments were mainly in response to replies that avr cannot be programmed w/o reset which turn out not to be quite true.

actually 2 way communication is not necessary to program avr. for the past couple years ive been flashing as many as 16 at a time. it does require a custom pc program. one of the great drawbacks of avrdude is the inability to do mosi only flashing.

actually you dont lose ability to program at all. ardunino bootloader works just as well by cycling power as by grounding reset. in fact by buffering the dtr output of the dongle there is little difference compared to using the reset pin. when using a real serial port instead of usb you dont even need to buffer.

for optiboot with 8mhz internal clk i found h=d6 l=e2 best. for 16mhz crystal i use h=d6 l=a7. these preserve ee on download as opposed to arduino settings which, for some peculiar reason, destroy the ee data every time.

imo atmels "flagship" is actually a garbage scow. in addition to costing 8x-10x more and not being able to power the target, mine had endless issues requiring firmware upgrade. inability to do 128k chips being just one. the usbasp units on the other hand behaved a-ok fron the start. and as mentioned none of the 300 or so i purchased from a variety or sources for clients required upgrade. maybe i just got lucky. a quick search on ebay will reveal hundreds in the $3 range.

i would like to see a link for the "bad" usbasp. this would help others avoid repeating the tragedy.

you may also find it necessary to fine tune the clock using osccal register. 30% of my last batch of m8 from digikey failed w/o this.

A bit hard to do before the chip is running isn't it?

i was referring to operation with bootloader using internal clock. regarding isp if attaching xtl dont work then try putting signal into x1.  if chip is still  no longer responding then rstdsbl is the issue and theres nothing to be done w/o 12v programmer.

there is no way a pullup can cause increased consumption if its the only thing on that pin. almost certainly there was other circuitry there. i will however add that imo the reset pullup serves no real purpose. recommendations for it are probably a holdover from the old days when mcus lacked sophisticated debounce circuit of avr. in most cases nothing at all should be connected to that pin. in rare situations where a long cable is attached a 1k series may be used but removed when cable is removed. during arduino upload with that cap to ftdi attached a 10k is needed but for stand alone i find anything at all connected to the reset pin is cause for trouble.

you may also find it necessary to fine tune the clock using osccal register. 30% of my last batch of m8 from digikey failed w/o this.