Theoretisch sollte der das können, aber womit? Ich dachte ja dass der Atmel-ICE so ungefähr alles kann, AVR-Studio7 lässt mir in der Kombi nur das Interface ISP zur Auswahl. Softwareproblem? Hat überhaupt schon mal jemand irgendeinen AVR mit dW geflasht?
H.Joachim S. schrieb: > Theoretisch sollte der das können Nicht wirklich. Überleg' doch einfach mal: - DW läuft über nur ein Signal - DW liegt auf demselben Pin wie Reset - DW ist standardmäßig deaktiviert D.h.: du brauchst zwingend erstmal ISP, um DW aktivieren zu können. Erst dann könntest du tatsächlich über DW programmieren. Das ist aber langsamer und unsicherer als über ISP, weil die gegenüber ISP fehlende Taktleitung und das fehlende Reset-Signal durch Protokoll ersetzt werden muss. Alles in allem ist es also sehr viel sinnvoller, gleich per ISP zu programmieren. DW heißt nicht umsonst ausgesprochen DebugWire: es ist vor allem zum Debuggen gedacht. Das Programierfeature ist da wohl nur aus zwei Gründen drinne: Erstens, um Breakpoints setzen zu können und zweitens, um wieder zu ISP zurückschalten zu können.
Ja das ist diese Krücke mit AVRs und den diversen Interfaces. Irgendwas ist immer. Jetzt hat man mal Debugging über einen Pin, reicht aber nicht zum Programmieren weil man trotzdem ISP braucht. Ich verwende den Tiny841 immer noch sehr häufig, aber wenn ich an das schnelle und unkomplizierte Flashen UND Debuggen via SWD denke, dann nervt es mich jedes mal wieder.
:
Bearbeitet durch User
Jaja, langsam nervt es. ISP, HV, JTAG, TPI, PDI, UPDI usw. Es wäre trotzdem gut wenn es ginge. Controller werden eh programmiert bestückt, dW-fuse wäre somit kein Problem. Platine soll aber komplett gelackt werden. Falls es mal ein update geben sollte (ist eigentlich nicht vorgesehen, aber wer weiss) könnte man dann den einen Pin rel. problemlos mit einer Nadel kontaktieren. Bootlader möchte ich eigentlich vermeiden. Also noch mal die Frage: geht es prinzipiell und wenn ja womit?
H.Joachim S. schrieb: > Also noch mal die Frage: geht es prinzipiell Ja. > und wenn ja womit? Das ist das Problem: da das DW-Protokoll nicht dokumentiert ist, gibt es AFAIK kein Tool jenseits der Atmel-Software dafür. Man könnte aber ein RE in Erwägung ziehen, denn vermutlich ist das Protokoll nicht sehr komplex und alle zum Programmieren von Flash und Fuses nötigen Teile müssen zwangsläufig vom AVR-Studio beim Debuggen benutzt werden.
c-hater schrieb: > Das ist aber > langsamer und unsicherer als über ISP, weil die gegenüber ISP fehlende > Taktleitung und das fehlende Reset-Signal durch Protokoll ersetzt werden > muss. Das ist kein zündendes Argument. Bei UPDI klappt es auch mit einer Leitung. Wie wäre es, Deine Schaltung mit einem ATtiny814 aufzubauen? Es braucht ein wenig Umgewöhnung, dafür sind diese neuen Teile deutlich flexibler. Nur so als Idee.
m.n. schrieb: > Das ist kein zündendes Argument. Doch, du hast es nur nicht verstanden. > Bei UPDI klappt es auch mit einer > Leitung. Es klappt auch bei DW. Es ist eben nur weniger schnell und/oder weniger sicher als ISP. Und das trifft auf UPDI ganz genauso zu. Sowas ergibt sich aus den grundlegenden Gesetzen der Informatik, um das sagen zu können, braucht man also nicht einmal die Protokolldetails zu kennen...
Danke schon mal - aber was gibt es denn diesseits der Atmel-Software/Werkzeuge? Ausser dem STK600 habe ich so ungefähr alles was es von Atmel/Microchip gibt. In Frage kämen ja eh nur der (ungeliebte) Dragon oder eben der Atmel-ICE. Studio7 lässt aber für beide kein Programmieren via dW zu.
H.Joachim S. schrieb: > Studio7 lässt aber für beide kein Programmieren via dW zu. Ja, weil es eben DW genau nur so nutzt, wie es gedacht war: zum Debuggen. Die Programmierfeatures von DW werden, wie schon mehrfach erwähnt, zwngend nur für zwei Sachen benutzt, die in diesem Kontext zwingend nötig sind: Setzen/Löschen von Breakpoints und zurückschalten zu ISP (also beim Beenden des Debugging).
c-hater schrieb: > Man könnte aber ein RE in Erwägung ziehen, denn vermutlich ist das > Protokoll nicht sehr komplex und alle zum Programmieren von Flash und > Fuses nötigen Teile müssen zwangsläufig vom AVR-Studio beim Debuggen > benutzt werden. Hab' gerade noch was zum Thema gefunden. Da hat schon jemand einen gut Teil des reverse engineering erledigt: http://www.ruemohr.org/docs/debugwire.html Mit den dort gegebenen Informationen sollte es (auch wenn das Protokoll noch nicht vollständig entschlüsselt ist) recht problemlos möglich sein, eine DW-Programmiersoftware zu schreiben. Jedenfalls, wenn man grundsätzlich programmieren kann...
Ok, also geht es, man müsste aber noch einiges an Arbeit reinstecken. Im Moment reicht der 441 mit ca. 500 Bytes frei. Da noch einen Bootlader reinzupressen mit dann kaum noch freiem Speicher - da macht eine update-Möglichkeit auch kaum Sinn. Also entweder ganz ohne Updatemöglichkeit oder auf den 841 wechseln samt one-wire-bootlader und dW vergessen. Irgendwie hätte ich es ganz gut gefunden wenn es direkt unterstützt würde.
H.Joachim S. schrieb: > Ok, also geht es, man müsste aber noch einiges an Arbeit reinstecken. Eine Q&D-Studie zum Nachweis der Korrektheit der Informationen (und damit der Machbarkeit des Programmers) würde man in ca. 30 Minuten programmieren können. Einen schon ziemlich schicken Programmer speziell für ATTiny441 (aber schon mit dem meisten nötigen Brimborium zur zukünftigen Unterstützung weiterer Typen) sollte man dann in etwa knapp einem Arbeitstag darauf setzen können. Jedenfalls, wenn man schon Sachen wie das Einlesen von Hexfiles auf Lager hat...
Microchip "Power Debugger" is a powerful development tool for debugging and programming AVR microcontrollers using UPDI, JTAG, PDI, debugWIRE, aWire, TPI or SPI target interfaces and ARM® Cortex®-M based SAM microcontrollers using JTAG or SWD target interfaces.
BlaBla schrieb: > Microchip "Power Debugger" is a powerful development tool for debugging > and programming AVR microcontrollers using UPDI, JTAG, PDI, debugWIRE, > aWire, TPI or SPI target interfaces and ARM® Cortex®-M based SAM > microcontrollers using JTAG or SWD target interfaces. That may be the case, but by my opinion absolutely doesn't match the TO's requirements. His intention is: misuse the DebugWire port for programming only. Under the condition, DW is enabled already (by using pre-programmed parts) und there is no possebility to access the ISP-Signals for re-programming, because Reset is disabled (implicitely by pre-enabled DW).
BlaBla schrieb: > Auch beim "ICE" möglich. And this will work under the stated preconditions? The GUI pictures are nice, but don't expose any information about this main issue...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.