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
Gast
#4776616
> Oder gibt's da noch n Trick?
Vorher flashen (und Fuses und Lockbits adäquat programmieren!), oder an
die AppNotes halten.
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
Gast
#4776666
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...
Gast
#4776707
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.
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?
Gast
#4776956
Ich flashe den ATtiny13 normalerweise, bevor er eingebaut wird.
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.
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! :)
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).
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.
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.
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?
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. http://www.ebay.de/itm/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.
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.
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.
Gast
#4777339
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. > > http://www.ebay.de/itm/261502260374 Gute Idee. Leider: Shipping: Does not ship to Germany
Gast
#4777347
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.
Gast
#4777402
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.
Pauper schrieb: > Gute Idee. Leider: Shipping: Does not ship to Germany Gibt es nur einen Lieferanten? https://www.aliexpress.com/item/Free-Shipping-SOIC8-SOP8-Test-Clip-For-EEPROM-93CXX-25CXX-24CXX-in-circuit-programming-New/1565888859.html?spm=2114.01010208.3.1.yMGOpZ&ws_ab_test=searchweb0_0,searchweb201602_2_10091_10090_10088_422_10089,searchweb201603_1&btsid=a72658a9-9790-4d2b-aa61-b1ba43df841d Gleiche Ausführung und sogar noch billiger.
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.
Gast
#4777551
Debuggen über Debug-Wire macht sowie keinen Spaß. Hast du mal ausprobiert, wie träge das abläuft?
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!
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?
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.
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.
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?
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.
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.
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.
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.
> 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?
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.