Hi, mir ist gerade so eine Idee gekommen. Mich wuerde einfach interessieren, ob das funktioniert. Und zwar kann man ja mit der RSTDISBL Fuse den RESET Pin als normalen I/O-Pin schalten. Das Problem dabei ist ja, dass man zum ISP-Programmieren den ATMEGA in den Reset-State versetzen muss. Kann man nicht den Brown-Out-Detector einschalten, die Versorgungsspannung knapp unter die Brown-Out-Detector-Grenze setzen (wo der IC ja trotzdem noch lauffaehig ist), und dann wie gewohnt ISP betreiben? Nicht dass ich unbedingt noch diesen einen I/O Pin braeuchte, davon abgesehen hat er ja auch andere Eigenschaften als die anderen I/O Pins, aber interessant waer es trotzdem zu wissen, ob jemand schonmal sowas versucht hat.
Probiert habe ich´s noch nicht, aber ich denke nicht, daß es funktioniert, da ich der Auffassung bin, daß das ISP-Modul mit dem Reset-Pin mehr oder weniger direkt verdrahtet ist.
Nach Schematic im Datenblatt siehts zwar nicht so aus, aber kann schon sein. Habe gerade mal getestet: Ohne BOD konnte ich den ATMEGA8 ca. 2,5 V runterwuergen ohne dass er seinen Dienst aufgegeben hat. Aber er ist (wegen internem RC-Oszi) langsamer geworden...
Philipp F. wrote: > Und zwar kann man ja mit der RSTDISBL Fuse den RESET Pin als normalen > I/O-Pin schalten. Das Problem dabei ist ja, dass man zum > ISP-Programmieren den ATMEGA in den Reset-State versetzen muss. Wenn Du den Reset-Pin als IO brauchst, dann brenn doch einfach nen Bootloader in den AVR. Damit funktioniert das Reprogrammieren immer. Und man muß nicht mehr darauf achten, ob sich die ISP-Pins mit der Applikation vertragen. Der Bootloader braucht nur (irgend) einen Pin. Peter
Das Thema ist zwar schon ein paar Jahre alt, doch es ist über Google leicht zu finden. Definitive Antworten waren bislang keine dabei, also habe ich das mal ausprobiert. Den Reset manuell (nicht über den Programmer / das ICSP Kabel) zu bedienen geht wunderbar. Einfach vor abschicken des avrdude den (noch aktiven) Reset-Pin mit GND verbinden und schon geht's. Es braucht nicht einmal das -F Flag. Dann habe ich den BOD auf 4,3V gestellt. Legt man 5V an, kann man diese 5V auch am Reset Pin messen. Legt man 3,3V an, ist der Reset-Pin (wie erwartet) auf 0V. Programmieren kann man den ATtiny (hier ein ATtiny85) auf die Art trotzdem nicht, es kommt keine Reaktion vom Chip. Schade eigentlich.
Vermutlich hält der BOD auch den Taktgenerator an, und ohne Takt geht ja auch ISP nicht....
Markus H. schrieb: > Legt man 3,3V an, ist der Reset-Pin (wie > erwartet) auf 0V. Woher nimmst Du diese Erwartung? Nach Lesen des Datenblattes erwarte ich genau das Gegenteil. Der Reset ist nur ein Eingang mit Pullup nach VCC. Siehe ATmega8 Datenblatt: Figure 14. Reset Logic Solange man ihn nicht per Fusebit ausschaltet, hat er gefälligst immer high zu sein. Das interne Reset wird nirgends nach außen gegeben. Das wäre auch Quatsch, man hätte dann eine ewige Selbsthaltung, er könnte nie auf high gehen. Peter
Peter Dannegger schrieb: > Markus H. schrieb: >> Legt man 3,3V an, ist der Reset-Pin (wie >> erwartet) auf 0V. > > Woher nimmst Du diese Erwartung? Das würde der beschriebenen Funktionsweise des BODs entsprechen. > Das interne Reset wird nirgends nach außen gegeben. Das wäre auch > Quatsch, man hätte dann eine ewige Selbsthaltung, er könnte nie auf high > gehen. Ich bin ja jetzt nicht gerade Experte für uC-Interna, doch woher nimmst Du diese Selbsthaltung? Und warum sollte es einen Unterschied zwischen einem internen und einem externen Reset geben? Für mich als Quasi-Laie ist das ganz einfach: Ist Reset Low, läuft das Ding im Programmiermodus; ist Reset High, läuft es im Standardmodus. Ein Wechsel in den Standardmodus stellt den Adresszähler auf Null. Der BOD ist von all dem unabhängig und zieht eben bei Spannungsmangel den Reset runter (und macht offensichtlich noch was Anderes). Atmel beschreibt im Datenblatt ja auch, wie man sich einen externen BOD basteln kann, von der Recheneinheit hängt der BOD also eher nicht ab.
Hi >Der BOD ist von all dem unabhängig und zieht eben bei Spannungsmangel >den Reset runter (und macht offensichtlich noch was Anderes). Nein. Die Resetquellen werden intern über eine Art Or zusammengeführt. Da erscheint nichts am Resetpin. MfG Spess
Markus H. schrieb: > Das würde der beschriebenen Funktionsweise des BODs entsprechen. Keinesfalls! Das BOD geht mit den anderen Resetquellen auf ein ODER-Gatter und dessen Ausgang auf das Internal Reset. Nirgends ist eine Rückführung auf den Reset-Pin zu sehen. Ich traue Atmel schon zu, Schaltpläne richtig zu zeichnen. Und keine undokumentierten Pfade einzubauen. Peter
Markus H. schrieb: > Und warum sollte es einen Unterschied zwischen > einem internen und einem externen Reset geben? Schon allein deshalb, weil man im MCUSR die Reset-Quelle später auslesen können muss. Kommt noch hinzu, dass man dann eine bidirektionale Padzelle bräuchte, denn das extern angelegte /RESET-Signal wird ja erst über einiges an Schaltungskram ins Innere geführt. Da müsste dann noch zusätzlich ein Ausgangstreiber dran, der das intern generierte Reset (von Brownout oder Watchdog) dort wieder nach draußen leitet. Wäre manchmal praktisch, sowas zu haben (bspw. um externe Peripherie zugleich zurücksetzen zu können), ist aber bei Standard-AVRs nicht vorhanden. Der einzige AVR, der sowas (aber mittels getrenntem Pin namens RSTON) hat, ist der ATmega128RFA1.
Markus H. schrieb: > Und warum sollte es einen Unterschied zwischen > einem internen und einem externen Reset geben? Kannst Du Dir selbst ganz einfach überlegen: Sobald man RSTDISBL setzt, ist der externe Reset nicht mehr da, sondern ein ganz normaler I/O-Pin. Es wäre daher allein schon Unsinn, nun bei aktivem BOD diesen I/O-Pin auf GND zu ziehen.
Frank M. schrieb: > Kannst Du Dir selbst ganz einfach überlegen: > > Sobald man RSTDISBL setzt, ist der externe Reset nicht mehr da, sondern > ein ganz normaler I/O-Pin. Es wäre daher allein schon Unsinn, nun bei > aktivem BOD diesen I/O-Pin auf GND zu ziehen. Vielleicht ist es noch nicht aufgefallen, doch ich habe das RSTDISBL noch gar nicht gesetzt, der Reset-Pin funktioniert noch. Von daher ist es auch nicht abwegig, dass der äussere Pin dem inneren entspricht. Schaltplan hin oder her. Die Atmel Datenblätter sind viel zu kompliziert, als dass ich allein aus deren Studium eine zuverlässige Aussage treffen könnte. Und wie man an an den Beiträgen vor dem Meinen sehen kann, gelang das auch sonst niemandem. Ansonsten vielen Dank für die vielen Erklärungen.
Markus H. schrieb: > Die Atmel Datenblätter sind viel zu > kompliziert, als dass ich allein aus deren Studium eine zuverlässige > Aussage treffen könnte. Es ist doch ganz einfach. Was nicht im Datenblatt drinsteht, hat er auch nicht. Also da nicht drinsteht, daß der Reset-Pin auch Ausgang ist, ist ers nicht. Ich habs auf dem STK500 nachgeprüft. Ich hab ein Blinkprogramm geladen und BOD auf 4V gesetzt. Wenn ich nun die VCC auf 3,3V setze, blinkt nichts mehr, da er ja im internen BOD-Reset ist. Aber der Reseteingang ist natürlich weiterhin high, also genau so, wie es laut Datenblatt sein muß. Ist durch den Pullup natürlich kleiner als VCC. Und beim ATtiny85 auch. Deine 0V waren also eindeutig ein Meßfehler. Peter
So, noch mal für die letzten Hinterwäldler: When programming the RSTDISBL Fuse Parallel Programming has to be used to change fuses or perform further programming. Nix mehr ISP. Schluss, aus, vorbei.
holger schrieb: > Nix mehr ISP. Das wurde doch schon vor 4 Jahren geklärt. Jetzt ging es darum, daß Markus meinte, ein dem Datenblatt widersprechendes Verhalten des Resetpins gefunden zu haben. Peter
Peter Dannegger schrieb: > Jetzt ging es darum, daß Markus meinte, ein dem Datenblatt > widersprechendes Verhalten des Resetpins gefunden zu haben. Eigentlich gar nicht. Es ging darum heraus zu finden, ob eventuell nicht dokumentiertes Verfahren funktioniert. Was der Reset-Pin dabei tut ist mir eigentlich wurscht, das habe ich nur beiläufig dazu geschrieben. > Es ist doch ganz einfach. Was nicht im Datenblatt drinsteht, hat er auch nicht. Im Datenblatt steht z.B. auch nicht drin, dass man einen Bootloader verwenden kann. Dennoch gibt es solche Bootloader. Hmm. Wer hat diesen Bootloader nur geschrieben? > Deine 0V waren also eindeutig ein Meßfehler. Noch mehr Beschuldigungen? Ich bedanke mich schon mal im Voraus.
Markus H. schrieb: >> Es ist doch ganz einfach. Was nicht im Datenblatt drinsteht, hat er auch > nicht. > > Im Datenblatt steht z.B. auch nicht drin, dass man einen Bootloader > verwenden kann. Dennoch gibt es solche Bootloader. Hmm. Wer hat diesen > Bootloader nur geschrieben? Also das war jetzt nich so intelligent ;-) Ansonsten gilt für deine Behauptung: Big claims require big proofs. Wenn du sagst du hast ein Verhalten welches dem DB widerspricht, oder gar eine Möglichkeit gefunden ISP ohne Reset-Pin zu machen, dann her damit. Reproduzierbar dokumentieren. Sonst ist alles nur heiße Luft. Eine verwackelte Messung unter mysteriösen Bedingungen an irgendnem Pin sagt da gar nichts aus. Und genau das stört die Leute hier und deshalb gibts diese Nicklichkeiten. gruß cyblord
Hi >Im Datenblatt steht z.B. auch nicht drin, dass man einen Bootloader >verwenden kann. Dennoch gibt es solche Bootloader. Hmm. Wer hat diesen >Bootloader nur geschrieben? Da es in diesem Thread um den ATMega8 geht solltest du mal das Kapitel Boot Loader Support – Read- While-Write Self-Programming im Datenblatt lesen. Dort findest du auch ein kleines Beispiel. MfG Spess
cyblord ---- schrieb: > gar > eine Möglichkeit gefunden ISP ohne Reset-Pin zu machen, dann her damit Genau das Gegenteil habe ich behauptet. Es geht nicht. Und offensichtlich war ich der Erste, der das mal ausprobiert (und dokumentiert) hat, anstatt nur über das Datenblatt zu oraklen. Zumindest konnte ich in ausgedehnten Google-Sessions kein entsprechendes Versuchsergebnis finden. Irgendwer hat sich dann zwei nebensächliche Worte raus gepickt und damit ein Fass aufgemacht. Prost!
Markus H. schrieb: > Irgendwer hat sich dann zwei nebensächliche Worte raus gepickt und damit > ein Fass aufgemacht. Prost! Es mag für Dich nebensächlich sein, wenn ein Eingang völlig unerwartet ein Ausgang wird, für mich ist es das nicht. Niemand möchte gerne Überraschungen erleben und dann vielleicht tausende Geräte zurückrufen müssen. Und deshalb habe ich das nachgeprüft und festgestellt, daß Deine Behauptung falsch ist. Es gibt natürlich solche ICs, aber dann steht das auch im Datenblatt, z.B. der PCF8584. Ich hatte damals allerdings das Datenblatt nicht gründlich gelesen. Der Reset dieses IC hing am Bus und hat damit das Display nach der Initialisierung resettet. Für das original Display war der Reset zu kurz und deshalb war das nicht aufgefallen. Der Nachfolgetyp wurde aber dunkel und ich guckte blöd aus der Wäsche. Durch ein SW-Update konnte das behoben werden. Man sollte daher nie etwas annehmen oder behaupten, was einfach nicht stimmt! Wenn Du später mal im Beruf Geräte entwickeln willst, wird Dir solche Nachlässigkeit schnell auf die Füße fallen. Peter
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.