avr_fred:
ahh yes - this picture was at the start of my whole arduous journey !!
it was so long ago i'd forgotten about it after i'd moved on to the ICSP method and then discovered the 'hack' of editing the avrdude.conf to trick the IDE in thinking the 328_ was a 328P.
SO;
i finally returned to THAT setup (in the picture above) - and LO AND BEHOLD !
i could actually upload a sketch to the Breadboard 328_ (having removed the original 328P on the UNO).
(the difference from before is that the IDE now thinks it is a 328P and not a 328_ - that generic error message of "avrdude: stk500_getsync(): not in sync: resp=0x00" would have saved me so much hassle if it had mentioned wrong chip signature* from the beginning !!)
this would confirm the bootlloader was still intact from being uploaded when ON the UNO board.
(i had not performed any write ICSP connection, just the read from the Board Detector sketch)
so; the UNO board 16U2 (USB-to-TTL chip) finds NO problem with the "outdated bootloader", nor the "wrong HFuse". (nor the actual signature of the chip being a 328_ )
is the CH340G really failing because of an "outdated bootloader" ?
i cannot imagine it makes a check of the fuses - that's all done by avrdude, right ?
side-question (been thinking of starting a new topic) - why is it the Arduino IDE is so averse to the 328_ chip? it does not appear in the boards.txt, and yet so many of the other chips atmega168/atmega168p, atmega325/atmega325p, atmega3250/atmega3250p, atmega329/atmega329p, atmega3290/atmega3290p all appear with BOTH versions....
