ATmega + Quarz

Jo.. die Seite kenne ich. Leider hilft sie mir jedoch nicht weiter, da 
sie die einzelnen Möglichkeiten von SUT_CKSEL im Atmel Studio 6 weder 
auflistet, noch näher erläutert. Im 4er Studio scheint die 
Auswahlmöglichkeit im Klartext angezeigt zu werden. Im 6er sind es 
leider nur irgendwelche schwer verständlichen Abkürzungen welche ich im 
1. Posting aufgelistet habe.

Kann ich denn den AVR mittels High Voltage Parallel Programming 
programmieren wenn ich keinen Quarz als externen Taktgeber auf dem 
Dragon zur Verfügung habe?  Habe ich dadurch irgendwelchen anderen 
Nachteile?

Oliver Lehmann schrieb:
> wenn ich keinen Quarz als externen Taktgeber auf dem
> Dragon zur Verfügung habe?

Wenn du ein CMOS-Inverter oder NAND oder NOR oder einen NE555 oder ein 
paar Transistoren oder einen OPamp hast, kannst du daraus einen 
Oszillator bauen. Ein Zweiter ATmega geht auch. Damit einfach in XTAL1 
einspeisen.

mfg mf

Ich habe auch noch einen 10 und einen 16 MHz Oszillator (also die 4-Pin 
Teile). kann ich den einfach mit seinem Takt-Pin an XTAL1 hängen?

Kommt beim XTAL1-Pin des AVR-Dragon HVPP-Interfaces kein Takt raus? 
Wollte mit meinem Oszi mal nachschauen, muss aber erstmal AVR Studio auf 
den Laptop installieren (Laptop ist wesentlich portabler als das riesen 
Oszi im Keller ;))

Spricht denn irgendwas gegen die dauerhafte Verwendung von HVPP?

Nee mit HVPP wäre es ja egal, der Dragon hat das drin.

Wenn du allerdings nur über ISP rangehst, ist ein externer Oszillator an 
XTAL1 eine möglichkeit, einen ver-fused-en Mega wieder zurückzugewinnen.

mfg mf

OK, also sehe ich jetzt 2 Möglichkeiten:

- ich baue mir eine kleine Schaltung welche z.B. einen 16MHz Takt 
erzeugt und flansche die an den AVR-Dragon ran und programmiere dann mit 
ISP weiter

- ich programmiere generell mit HVPP

Spricht denn was gegen HVPP (12V am Reset-Pin?)

Es geht hier nicht um das "retten" eines ATmega, sondern ums regulaere 
programmieren - was sicherlich sehr oft passieren muss, da ich erst am 
Anfang der Entwicklung meines Systems stehe. Man kann also bestimmt von 
einigen hundert Programmiervorgaengen ausgehen - ist dafuer HVPP 
ungeeignet?

Oliver Lehmann schrieb:
> Man kann also bestimmt von
> einigen hundert Programmiervorgaengen ausgehen - ist dafuer HVPP
> ungeeignet?

Da würd ich eher zu ISP raten - vor allem dann, wenn dein Controller 
schon im Zielsystem verbaut ist. Da muss halt nur eine ISP-Buchse mit 
ins Zielsystem eindesigned werden. Spart das Umstecken, was die Pins mit 
der Zeit in Mitleienschaft zieht.

Was die Fuses angeht, die stellst du bestimmt mal falsch ein. Dann 
kannst du den Controller aber auch mit dem externen Takt im Zielsystem 
retten. Oder eben doch nochmal rausholen, auf den Dragon, und dort die 
Fuses auf ein funktionierenden Wert einstellen.

Jedesmal beim Programmieren die Fuses mit zu verändern oder neu zu 
schreiben, ist keine gute Idee und auch nicht nötig.

mfg mf

Hatte auch nicht vor, die Fuses jedesmal neu zu setzen ;)
Habe jetzt mal HVPP ausprobiert und scheint zu funktionieren.
ISP mit einzufuegen in die Schaltung war mir jetzt erstmal "zu viel" - 
aufs fertige Board wirds mit raufkommen - ja - aber aktuell haengt an 
den Pins des ATmega eine SD-Card und da wollte ich jetzt nicht noch ISP 
mit reinfummeln.