Forum: Mikrocontroller und Digitale Elektronik Attiny DebugWire SPI DWEN - Wie blöd ist das denn?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Christoph M. (chrito)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

hab heute einen Attiny 13 ausprobiert. Frisch aus der Tüte 
funktioniert DebugWire nicht. Dazu muss man erst die Fuse DWEN setzen. 
Und dafür benötige ich zuerst die SPI-Schnittstelle.

Also sechs Leitungen*, damit man später drei verwenden kann! Wie blöd 
ist das denn? Wenn ich den Attiny in der Produktion schön im Schaltkreis 
verbaut hab, komm ich doch nicht immer an alle sechs Leitungen ran???

Oder gibt's da noch n Trick?

Danke!
VG
Christoph

*MISO, MOSI, SCK, dw, VCC, GND

von g457 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Oder gibt's da noch n Trick?

Vorher flashen (und Fuses und Lockbits adäquat programmieren!), oder an 
die AppNotes halten.

von Axel S. (a-za-z0-9)


Bewertung
5 lesenswert
nicht lesenswert
Christoph M. schrieb:
> hab heute einen Attiny 13 ausprobiert. Frisch aus der Tüte
> funktioniert DebugWire nicht. Dazu muss man erst die Fuse DWEN setzen.
> Und dafür benötige ich zuerst die SPI-Schnittstelle.
> Also sechs Leitungen*, damit man später drei verwenden kann! Wie blöd
> ist das denn?

Dein Post in einem Wort zusammengefaßt: Mimimi

von Dennis (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Christoph M. schrieb:
> hab heute einen Attiny 13 ausprobiert. Frisch aus der Tüte
> funktioniert DebugWire nicht. Dazu muss man erst die Fuse DWEN setzen.
> Und dafür benötige ich zuerst die SPI-Schnittstelle.
>
> Also sechs Leitungen*, damit man später drei verwenden kann! Wie blöd
> ist das denn?

Auch wenn hier die Hälfte der hier anwesenden Möchtegern- bzw. 
Hobbyprogrammierer aufschreien werden: Wer AVR kennt, nimmt was anderes 
:-)

Es gibt so schöne Mikrocontroller am Markt, wer da bei AVR bleibt, der 
ist selber schuld...

von Karl M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Nun ich spiele über einen SOIC Adapter einen seriellen Bootloader auf 
den attiny85 und kann dann später einfach neue Programme einspielen oder 
über die selbe Leitung, einen Software Uart mit Fifo TX verwenden, um 
z.B. Debugausgaben zu machen.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Es gibt so schöne Mikrocontroller am Markt, wer da bei AVR bleibt, der
> ist selber schuld...

Christoph M. schrieb:
> Wie blöd ist das denn?

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Ich flashe den ATtiny13 normalerweise, bevor er eingebaut wird.

von Harald A. (embedded)


Bewertung
3 lesenswert
nicht lesenswert
Christoph M. schrieb:

> Oder gibt's da noch n Trick?

Egal welcher Prozessor - es gibt eigentlich immer einige Pins, die man 
für die initiale Programmierung benötigt. Mit einer geschickten 
Auslegung von Ein- und Ausgängen, ggf. mit einem Widerstand in der 
Leitung (damit man den angelegten Pegel im Programmierfall übersteuern 
kann) braucht man meist nichts opfern.

von Christoph M. (chrito)


Bewertung
0 lesenswert
nicht lesenswert
Harald A. schrieb:

> Egal welcher Prozessor - es gibt eigentlich immer einige Pins, die man
> für die initiale Programmierung benötigt.

Na das is ja grad der Witz: DebugWire käme mit einem (!) Pin aus. Wenn 
man nicht ab Werk die Fuse DWEN gelöscht hätte. Sperren könnte man die 
Funktion dann ja immer noch.

> Mit einer geschickten
> Auslegung von Ein- und Ausgängen, ggf. mit einem Widerstand in der
> Leitung (damit man den angelegten Pegel im Programmierfall übersteuern
> kann) braucht man meist nichts opfern.

Ja, und da sind wir dann beim Basteln und Frickeln. Für mich der Beweis, 
dass das Ding (zumindest an dieser Stelle) ne Fehlkonstruktion ist.

Bei sechs GPIOs, von denen vier für den Programmierbus benötigt werden, 
sieht das doch etwas düster aus. Und wenn man die SMD-Variante verwenden 
muss (es wird eine sehr kompakte Lösung), ist mir auch nicht klar, wie 
man den SMD-Tiny ohne großen Aufwand extern programmieren möchte!? :/

Hab früher viel mit PICs gearbeitet, vielleicht ne gute Alternative...

Trotzdem Danke für den Tipp, Harald! :)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
> Wenn man nicht ab Werk die Fuse DWEN gelöscht hätte.

Damit würde sich Atme^H^H^H^HMicrochip gewiss viele Freunde machen:
danach geht nämlich kein ISP-Zugriff mehr, nichtmal mehr ein normaler
Reset.  Man kann dann nur noch mit dem (vergleichsweise teuren)
Debugger ran.

Ja, man könnte jetzt über Sinn und Unsinn von debugWIRE streiten,
beim Xmega haben sie es ja mit PDI auch anders gelöst (aber mit
einem Pin mehr).

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
Kennst du überhaupt den Unterschied zwischen Debugen und Programmieren?! 
Der Tiny ist über SPI zu programmieren und über DW zu debugen - fertig. 
Wenn man sich für einen µC entscheidet sollte man halt vorher das 
Datenblatt lesen.

von F. F. (foldi)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ja, man könnte jetzt über Sinn und Unsinn von debugWIRE streiten,

Wenn man wenigstens im Studio da wieder raus kommen würde. Ich weiß, das 
haben schon viele gesagt, dass es geht. Bei mir ging das nie, auch mit 
allen Tipps nicht.
Habe ja schon länger nichts mehr gemacht, aber da ich mit dem ICE auch 
nur eben probiert habe, ob die verschiedenen Verfahren funktionieren, 
wäre das mal was für die nähere Zukunft.

von Christoph M. (chrito)


Bewertung
0 lesenswert
nicht lesenswert
Rene K. schrieb:
> Kennst du überhaupt den Unterschied zwischen Debugen und Programmieren?!

Nein, den Unterschied kenn ich nicht, bin zu dumm.

> Der Tiny ist über SPI zu programmieren und über DW zu debugen - fertig.

Stimmt nicht: Ist die Fuse DWEN gesetzt, kann man ihn über DebugWire 
sowohl debuggen als auch programmieren.

Jörg Wunsch schrieb:
> Damit würde sich Atme^H^H^H^HMicrochip gewiss viele Freunde machen:
> danach geht nämlich kein ISP-Zugriff mehr, nichtmal mehr ein normaler
> Reset.  Man kann dann nur noch mit dem (vergleichsweise teuren)
> Debugger ran.

Ja, verstehe. Aber wie macht man es dann mit den Dingern in der 
Serienfertigung? Werden die dann über ISP vor dem Einlöten geflasht?

von Herr M. (herrmueller)


Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
> Und wenn man die SMD-Variante verwenden
> muss (es wird eine sehr kompakte Lösung), ist mir auch nicht klar, wie
> man den SMD-Tiny ohne großen Aufwand extern programmieren möchte!? :/

Mit sowas für 4 fuffzig.

Ebay-Artikel Nr. 261502260374

Christoph M. schrieb:
> Bei sechs GPIOs, von denen vier für den Programmierbus benötigt werden,
> sieht das doch etwas düster aus

Es hindert Dich nichts, die 6 GPIOs( eigentlich 5, wenn man den Reset 
nicht abschalten will ) trotzdem für Deine Anwendung zu nutzen.

Ich habe den Attiny13 SMD schon oft benutzt und habe ihn mit dem Clip 
Adapter in der Schaltung programmiert.

siehe ->
Harald A. schrieb:
> Egal welcher Prozessor - es gibt eigentlich immer einige Pins, die man
> für die initiale Programmierung benötigt. Mit einer geschickten
> Auslegung von Ein- und Ausgängen, ggf. mit einem Widerstand in der
> Leitung (damit man den angelegten Pegel im Programmierfall übersteuern
> kann) braucht man meist nichts opfern.

: Bearbeitet durch User
von F. F. (foldi)


Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
> Ja, verstehe. Aber wie macht man es dann mit den Dingern in der
> Serienfertigung? Werden die dann über ISP vor dem Einlöten geflasht?

Bei den Tiny10 mache ich das so, da ja sonst der Vorteil der geringen 
Größe wieder futsch wäre. Außerdem kosten sie so wenig, wenn mal was 
geändert werden müsste, kann ich auch gleich einen neuen Tiny auflöten.

von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
> Aber wie macht man es dann mit den Dingern in der
> Serienfertigung? Werden die dann über ISP vor dem Einlöten geflasht?

Wenn du genug bestellst, bekommst du sie vom Hersteller programmiert 
geliefert.

von Pauper (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Herr M. schrieb:
> Christoph M. schrieb:
>> Und wenn man die SMD-Variante verwenden
>> muss (es wird eine sehr kompakte Lösung), ist mir auch nicht klar, wie
>> man den SMD-Tiny ohne großen Aufwand extern programmieren möchte!? :/
>
> Mit sowas für 4 fuffzig.
>
> Ebay-Artikel Nr. 261502260374


Gute Idee. Leider: Shipping: Does not ship to Germany

von Stefan ⛄ F. (stefanus)


Bewertung
4 lesenswert
nicht lesenswert
Der eine möchte über Debug-Wire programmieren, weil es dann weniger 
Drähte benötigt.
Der andere will gerade nicht über Debug-Wire programmieren, weil es ihm 
zu langsam ist.
Der Dritte will Debugging aus Sicherheitsgründen verbieten.

Der Weise bemängelt nicht Dinge, die er niemals beeinflussen kann, 
sondern nutzt seine Zeit für erquickenderes.

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hp M. schrieb:
> Christoph M. schrieb:
>> Aber wie macht man es dann mit den Dingern in der
>> Serienfertigung? Werden die dann über ISP vor dem Einlöten geflasht?
>
> Wenn du genug bestellst, bekommst du sie vom Hersteller programmiert
> geliefert.

Oder mit seinem Distributor sprechen, einige bieten eben auch fertig 
programmierte und getestete Lösungen an. Z.b EBV,Arrow programmieren Dir 
die Bauteile und Du zahlst nur für die erfolgreich programmierten und 
getesteten Prozessoren. Da sind die Bestellmengen auch geringer als 
direkt vom Hersteller.

von Georg G. (df2au)


Bewertung
0 lesenswert
nicht lesenswert

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:

> Stimmt nicht: Ist die Fuse DWEN gesetzt, kann man ihn über DebugWire
> sowohl debuggen als auch programmieren.

Jein.  Du kannst Flash und EEPROM damit beschreiben.  Fusebits
oder gar Lockbits setzen kannst du damit nicht, und du brauchst
unbedingt ein Setup, welches auch erstmal überhaupt debugWIRE-fähig
ist: maximal einen Pullup von 4,7 bis 10 kΩ an /RESET, und auf keinen
Fall größere Kapazitäten.

Das beißt sich natürlich mit der empfohlenen Beschaltung von /RESET
für den normalen, EMV-robusten Betrieb, denn diese sieht einen
Kondensator von 10 nF an /RESET vor.

> Werden die dann über ISP vor dem Einlöten geflasht?

Ja, oder man gestaltet sich die Schaltung eben so, dass sie die
ISP-Signale tolerieren kann.  Worst case könnte man dafür als
Erkennung ein gezogenes /RESET nehmen, denn das ist während ISP
immer aktiv.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Debuggen über Debug-Wire macht sowie keinen Spaß. Hast du mal 
ausprobiert, wie träge das abläuft?

von Christoph M. (chrito)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Debuggen über Debug-Wire macht sowie keinen Spaß. Hast du mal
> ausprobiert, wie träge das abläuft?

Naja, find es jetzt nicht so träge. Mein Programm für den Tiny ist aber 
auch relativ kurz (85 Zeilen).

Danke für eure Tipps!

von Axel S. (a-za-z0-9)


Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ja, man könnte jetzt über Sinn und Unsinn von debugWIRE streiten

Ich sehe da nicht viel Streitpotential. dW ist eine Krücke. Ein 
Zugeständnis an jene, die glauben selbst auf den Tinies nicht auf den 
Debugger verzichten zu können.

In der praktischen Handhabung ist dW ein ziemlicher Albtraum. Man kann 
Reset nicht so beschalten, wie man es eigentlich wollen würde. Die 
Leitung zwischen Tool und Target muß wirklich kurz sein. Das Ein-/und 
Ausschalten der dW Funktionalität ist aufwendiger als man sich wünschen 
würde etc. pp.

Atmel tut schon richtig, dW im Auslieferungszustand zu deaktivieren.

Sieht das ernsthaft jemand anders?

: Bearbeitet durch User
von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Sieht das ernsthaft jemand anders?

Ja. Sofern sich deine Frage nicht auf die letzte Aussage bezieht.

Bei einem vollgestopften Atmega 328 ist DW allerdings wirklch kein 
Spass. Da gebe ich dir vollkommen recht.

: Bearbeitet durch User
von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Jörg W. schrieb:
>> Ja, man könnte jetzt über Sinn und Unsinn von debugWIRE streiten
Lass uns das tun. ;)

> Ich sehe da nicht viel Streitpotential. dW ist eine Krücke. Ein
> Zugeständnis an jene, die glauben selbst auf den Tinies nicht auf den
> Debugger verzichten zu können.
Du bist doch auch in erster Linie Profientwickler und nicht Masochist? 
;)
Warum möchtest Du dann freiwillig auf den Debugger verzichten?

> In der praktischen Handhabung ist dW ein ziemlicher Albtraum. Man kann
> Reset nicht so beschalten, wie man es eigentlich wollen würde. Die
> Leitung zwischen Tool und Target muß wirklich kurz sein.
Auf dem Entwicklungsmuster wird der Reset-Pin anders beschaltet, im 
einfachsten Fall wird der kleine Kappa entfernt.

> Das Ein-/und
> Ausschalten der dW Funktionalität ist aufwendiger als man sich wünschen
> würde etc. pp.
Das wiederum ist tatsächlich typischer Atmel-Pfusch.
Einer von vielen Gründen einen STM32x0 zu bevorzugen.
Außer man braucht einen SOT23-6-Controller, weil man zwar keinen Platz 
auf der LP hat, aber das 2,6mm x 2,7mm WLCSP36-Gehäuse vom STM32F042T 
nicht gelötet bekommt. Aber halt - die ganz kleinen Controller haben gar 
kein debugWire, oder? ;)

> Atmel tut schon richtig, dW im Auslieferungszustand zu deaktivieren.
> Sieht das ernsthaft jemand anders?
Ja, ich. Weil diese Entscheidung in der Serie entweder einen zweiten 
Fertigungsschritt oder verlorenen Leiterplattenplatz bedeutet.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Marcus H. schrieb:
> Weil diese Entscheidung in der Serie entweder einen zweiten
> Fertigungsschritt oder verlorenen Leiterplattenplatz bedeutet.

Das musst du aber nun erklären.

Dass man Entwicklungsmuster anders benutzt als das Serienprodukt,
da geh' ich völlig mit dir mit.  Aber du würdest ernsthaft in
einem Serienprodukt die Debug-Schnittstelle offenlassen?

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Marcus H. schrieb:
>> Weil diese Entscheidung in der Serie entweder einen zweiten
>> Fertigungsschritt oder verlorenen Leiterplattenplatz bedeutet.
>
> Das musst du aber nun erklären.
>
> Dass man Entwicklungsmuster anders benutzt als das Serienprodukt,
> da geh' ich völlig mit dir mit.  Aber du würdest ernsthaft in
> einem Serienprodukt die Debug-Schnittstelle offenlassen?
Kommt drauf an.

Was Programmieroptionen bei der Fertigung betrifft - hier gibt's ja eine 
Riesenpalette von Vorprogrammieren, Nadeladapter, Platinenstecker, 
Stecker.

Der Vorteil von debugWire und noch viel mehr an JTAG ist die 
Diagnosefähigkeit der Baugruppe über diese Schnittstelle.

debugWire würde sich, so es denn ab Atmel-Fab aktiv wäre, als 
minimalistische Inbetriebnahmeschnittstelle anbieten.
Danach würde man die MCU mittels Lock-Fuses verriegeln.

Wie man mit Debug-Schnittstellen in der Serie umgeht, muss man je nach 
Produkt entscheiden. Es läuft auf eine passende Kombination aus 
Weglassen von Bauteilen und Setzen von Lock-Fuses hinaus.

AFAIR kann man den debugWire per debugWire deaktivieren.
D.h. falls die Schnittstelle ab FAB offen wäre, könnte man sich bei der 
Werksprogrammierung entscheiden, was man braucht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marcus H. schrieb:
> Danach würde man die MCU mittels Lock-Fuses verriegeln.

Über debugWIRE?

Vergiss es.  Das Ding ist keine Debugschnittstelle, sondern eine
Monitor-Firmware.  (Hieß ganz am Anfang auch "MonCon", findet man
noch in irgendeinem alten Dokument.)  Die kann daher nur genau das
zugreifen, was halt die CPU in einem AVR machen kann.  Lock- und
Fusebits gehören (aus gutem Grund) nicht dazu.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Marcus H. schrieb:
>> Danach würde man die MCU mittels Lock-Fuses verriegeln.
>
> Über debugWIRE?
>
> Vergiss es.  Das Ding ist keine Debugschnittstelle, sondern eine
> Monitor-Firmware.  (Hieß ganz am Anfang auch "MonCon", findet man
> noch in irgendeinem alten Dokument.)  Die kann daher nur genau das
> zugreifen, was halt die CPU in einem AVR machen kann.  Lock- und
> Fusebits gehören (aus gutem Grund) nicht dazu.

Danke für die Aufklärung. Wenn dem so ist, wie von Dir beschrieben, dann 
gebe ich Dir in Bezug auf debugWire recht. Da sehe ich mal wieder, wie 
weit ich mittlerweile von den AVRs weg bin.

Der allgemein gehaltene Rest meiner Ausführung ist aber Stand der 
Technik. Ich hatte während des Schreibens Themen wie "Boundary Scan via 
JTAG" im Kopf.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marcus H. schrieb:
> Ich hatte während des Schreibens Themen wie "Boundary Scan via JTAG" im
> Kopf.

Sind aber halt vier Drähte.  Hat AVR ja auch schon seit Jahrzehnten,
debugWIRE war dann nur die Sparversion für low pincount.  Man muss
aber auch zugeben, dass sie das zu einer Zeit erfunden hatten, als
eben auch ARM noch kein SWD kannte, sondern nur JTAG.

von Simon A. (seimen)


Bewertung
0 lesenswert
nicht lesenswert
> Mit einer geschickten
> Auslegung von Ein- und Ausgängen,

Bedeutet das MOSI und SCK darf nur als Eingang und MISO nur als Ausgang 
definiert werden?

> ggf. mit einem Widerstand in der
> Leitung (damit man den angelegten Pegel im Programmierfall übersteuern
> kann) braucht man meist nichts opfern.

Wenn ich zum Beispiel auf MOSI ein Eingangssignal in meiner Schaltung 
habe, zwischen das Eingangssignal einen Widerstand schalten während der 
Programmierung, damit das MOSI Kabel übersteuern kann!?

Wie erkennt ein uC eigentlich, dass eine SPI Kommunikation nun 
stattfindet? Bei uC mit Slave Select sollte es über den Slave Select 
Eingang erkannt/gestartet werden, nehme ich an. Wie verhält es sich aber 
bei z.B. einem ATTiny13A, der kein SS-Pin hat?

Wird das Programm aus dem Flash während der Kommunikation angehalten?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Simon A. schrieb:
> Wie verhält es sich aber bei z.B. einem ATTiny13A, der kein SS-Pin hat?

/RESET fungiert bei der Programmierung als slave select.

> Wird das Programm aus dem Flash während der Kommunikation angehalten?

Da sich der Controller zwangsweise im Reset befindet, natürlich.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.