AVR programmieren über DebugWire?

[Stefan (Gast)]

Bis vor kurzem war ich noch überzeugt, dass man AVRs auch via Debugwire 
programmieren kann. Ich bin mir recht sicher, dass beim Debuggen das 
Programm ins Flash übertragen wird und anschliessend auch gespeichert 
bleibt.
Jetzt habe ich hier einen Tiny45 in der Schaltung, der nach dem Abziehen 
des MKII einfach keinen Mucks macht, obwohl zuvor beim Debugging alles 
noch lief.
Bin ich da irgendwo falsch abgebogen ?

Stefan


---

[Knut B. (Firma: TravelRec.) (travelrec)]

Stell doch mal die DWEN-Fuse zurück ;-)

[Jörg W. (dl8dtl) (Moderator)]

Stefan wrote:

> Bis vor kurzem war ich noch überzeugt, dass man AVRs auch via Debugwire
> programmieren kann.

Ja, es geht, aber es ist nach meinen Erfahrungen schon nicht so
zuverlässig (und ich glaube auch nicht so schnell) wie ISP.  Das
liegt ganz einfach daran, dass das Ganze ein 1-wire-Bus ist, der
ist natürlich immer frickeliger als das 3-wire SPI.

> Jetzt habe ich hier einen Tiny45 in der Schaltung, der nach dem Abziehen
> des MKII einfach keinen Mucks macht, obwohl zuvor beim Debugging alles
> noch lief.

Im ungünstigen Moment abgezogen?  Prinzipiell laufen die Teile auch
mit eingeschalteter DWEN-Fuse natürlich ohne ICE los.

[Peter D. (peda)]

Jörg Wunsch wrote:

> Ja, es geht, aber es ist nach meinen Erfahrungen schon nicht so
> zuverlässig (und ich glaube auch nicht so schnell) wie ISP.  Das
> liegt ganz einfach daran, dass das Ganze ein 1-wire-Bus ist, der
> ist natürlich immer frickeliger als das 3-wire SPI.

Liegt aber nicht an der Anzahl der Drähte.

Mein Bootloader geht über einen Draht genauso schnell, wie mit 
getrennten RXD/TXD Leitungen.
Und bezüglich Zuverlässigkeit habe ich auch keinen Unterschied gemerkt 
(3m Kabel bei 115200Baud).

Wenn man Debugwire nicht braucht oder auch den Resetpin als IO verwenden 
will, würde ich zum Bootloader raten.


Peter

[Stefan (Gast)]

"Wenn man Debugwire nicht braucht oder auch den Resetpin als IO 
verwenden
will, würde ich zum Bootloader raten."

Genau das werde ich jetzt auch machen. Das Grundgerüst steht; soweit ist 
alles verifiziert. Jetzt fehlt nur noch die Funktionalität rund um den 
Reset-Pin.


Danke...

[Jörg W. (dl8dtl) (Moderator)]

Peter Dannegger wrote:

> Liegt aber nicht an der Anzahl der Drähte.

Doch, notgedrungen.  Bei 1-wire hast du immer die RC-Konstanten der
tatsächlichen Implementierung als Unwägbarkeit, und da es ein Bus
ist, wird er nur in eine Richtung (pull-down) getrieben, in die
andere Richtung ,,driftet'' er also vergleichsweise langsam zurück.
Du kannst natürlich ein aggressives Timing zimmern, das genau für
eine RC-Konstante läuft, aber wenn du eine gewisse Toleranz für das
Setup akzeptieren willst/musst, muss das Timing großzügiger sein.

Außerdem braucht's wohl sinnvollerweise eine CRC dafür, während
ein 3-wire-Bus normalerweise ohne eine solche gefahren wird.

[Christian U. (z0m3ie)]

Naja ich find I2C funktioniert auch ganz gut ohne CRC. Schaut mir auch 
bei DebugWire so aus als ob das ohne gefahren wird. Scheint sogar über 
die SPI gemacht zu werden.

[Jörg W. (dl8dtl) (Moderator)]

Christian Ulrich wrote:

> Schaut mir auch
> bei DebugWire so aus als ob das ohne gefahren wird.

Ich hab' mir das Protokoll nicht angesehen, aber ich fände das
ziemlich leichtsinnig.  Dallas macht bei 1-wire auch wenigstens
eine 8-bit-CRC.

> Scheint sogar über
> die SPI gemacht zu werden.

Definitiv nicht.  DebugWire ist ein 1-wire-Protokoll, es braucht
außer GND nur noch die /RESET-Leitung.  ISP brauchst du nur zum
Ein- und Ausschalten des dW.  Das Ausschalten funktioniert
ziemlich mühselig.  Mit einem speziellen Kommando wird der
/RESET-Pin temporär (bis zum nächsten power cycle) wieder in
Betrieb genommen, sodass man ihn wieder für normales ISP zur
Verfügung hat.  Das kann man dann benutzen, um die DWEN-Fuse
wieder zu löschen.  Mann kann sie aber auch gleich gesetzt lassen
und das ISP nur für einen neuen Download nehmen.  Am Ende muss man
aber in jedem Falle einen power cycle machen, damit der
temporäre Zustand wieder aufgehoben wird.

[Peter D. (peda)]

Jörg Wunsch wrote:

> Doch, notgedrungen.  Bei 1-wire hast du immer die RC-Konstanten der
> tatsächlichen Implementierung als Unwägbarkeit, und da es ein Bus
> ist, wird er nur in eine Richtung (pull-down) getrieben, in die
> andere Richtung ,,driftet'' er also vergleichsweise langsam zurück.

Jein.
RS-232 Pegel ist zwar -/+10V, aber der MAX232 ist TTL-kompatibel (<0,8V 
= Low, >2,4V = high).

Für high macht mein AVR +5V, für low geht er in tristate und dann ziehen 
ihn die -10V des TXD über die 4,7k ordentlich schnell wieder auf 0V.
Sieht auf dem Oszi sehr schön aus.


> Du kannst natürlich ein aggressives Timing zimmern, das genau für
> eine RC-Konstante läuft, aber wenn du eine gewisse Toleranz für das
> Setup akzeptieren willst/musst, muss das Timing großzügiger sein.

Oder einfach ne niedrigere Baudrate nehmen.


> Außerdem braucht's wohl sinnvollerweise eine CRC dafür, während
> ein 3-wire-Bus normalerweise ohne eine solche gefahren wird.

Ich mach ne CRC-16


Peter