Hallo, ich habe gerade versucht einen ATMega1284P im AVR Studio so einzustellen, das er mit einem externen Quarz (11,0592Mhz) läuft. Nur dummerweise war die Fuse Auswahl EXTLOFXTAL_32KCK_65MS wohl die falsche. Jetzt kann ich den Controller nicht mehr programmieren. Was ist da falsch gelaufen? Welche Einstellung hätte ich haben müssen? Und vor allem wie komme ich nun den wieder dazu den Controller zu programmieren? :-( gruß Matthias
MSP2811 schrieb: > Und vor allem wie komme ich nun den wieder dazu den Controller zu > programmieren? :-( Siehe: http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en MfG
Einen ext. Takt an XTAL1 legen (z.B quarzoszillator). Dann sollte man wieder mit ihm sprechen können. Peter
MSP2811 schrieb: > ich habe gerade versucht einen ATMega1284P im AVR Studio so > einzustellen, das er mit einem externen Quarz (11,0592Mhz) läuft. Nur > dummerweise war die Fuse Auswahl EXTLOFXTAL_32KCK_65MS wohl die falsche. > Jetzt kann ich den Controller nicht mehr programmieren. Hallo, welcher Fuse-Einstellung entspricht "EXTLOFXTAL_32KCK_65MS"? Die Bezeichnung kommt im Datenblatt nirgends vor. Ist sie im AVR-Studio erklärt? Ich könnte vermuten, dass damit "Low Frequency Crystal Oscillator" gemeint ist. Genauere Infos findest du im Datenblatt des ATmega1284P in den Kapiteln 9.2 und 27.2 (dort in Tabelle 27-5). > Was ist da falsch gelaufen? Welche Einstellung hätte ich haben müssen? Ich vermute CKSEL= 0b0111 aber bitte schau ins Datenblatt. > Und vor allem wie komme ich nun den wieder dazu den Controller zu > programmieren? :-( Mit einem HV-Programmer. Oder du schließt das Quarz an, für das du den Controller versehentlich programmiert hast. Oder, was vielleicht auch geht, du ersetzt das 11-MHz-Quarz vorübergehend durch einen Kondensator, z.B. 100 pF oder 1 nF. Aber ohne Gewähr, das hab ich noch nicht getestet... Zusätzlich ist es dann notwendig, die ISP-Programmierfrequenz auf möglichst unter 1 KHz zu drehen. P.S.: Ich les grad die Idee von Peter Sieg, das ist auch ein guter Tipp!
Hi >welcher Fuse-Einstellung entspricht "EXTLOFXTAL_32KCK_65MS"? Die >Bezeichnung kommt im Datenblatt nirgends vor. Ist sie im AVR-Studio >erklärt? Ich könnte vermuten, dass damit "Low Frequency Crystal >Oscillator" gemeint ist. Richtig: EXTLOFXTAL_32KCK_65MS: Ext. Low-Freq. Crystal; Start-up time: 32K CK + 65 ms MfG Spess
Hi, danke schonmal für die schnellen Antworten. Da der Controller ein SMD Bauteil ist, kann ich den auch nicht einfach ausbauen. Aber ich habe jetzt mal einen 32,768 Khz quarz anstelle des 11,059 Mhz eingelötet. Damit wird dann das zuletzt aufgespielte Programm auch tatsächlich ausgeführt, wenn auch extrem langsam. Soweit so gut. Soweit ich das jetzt verstanden habe muss ich über den ISP mit maximal einem Viertel der Systemfrequenz programmieren. 32,786 Khz 4 8 (Teiler) ergeben dann eine Frequenz von < 1024 Hz. Im AVR Studio kann ich für den AVRISP mkII aber nur Frequenzen ab 2Khz einstellen. Gibt es ein Tool, welches auch den mkII verwendet, welches mit niedrigerer Frequenz programmieren kann? Alternativ könnte ich auch über einen 2ten Controller einen eigenen Takt erzeugen ( z.B. 100 Khz). Kann ich den da auch so auf XTAl 1 draufgeben mit 5V ohne das der Controller schaden nimmt? Oder ist das iregdnwie Spannungs auf kleinere Werte begrenzt mit meiner derzeitigen Fuse Einstellung? Der vollständigkeit halber: Das AVR Studio zeigte mir für die Fuse Register folgendes an: Ext FF High D9 Low 62 gruß Matthias
Der Controller läuft wieder :-) mit dem AVR Studio 4 ließen sich auch geringere Frequenzen für den ISP einstellen. Vielen dank nochmals für die Antworten
Bedank Dich bei Atmel für den Mist, dass sie es noch nicht geschafft haben, einen vernüftigen ISP zu designen ... :-)
Pete K. schrieb: > Bedank Dich bei Atmel für den Mist, dass sie es noch nicht geschafft > haben, einen vernüftigen ISP zu designen ... :-) In den XMegas ist es dank PDI wesentlich besser geworden. Aber klar, das die aus Kompatibilitaetsgruenden die alten ICs nicht anfassen. MfG
Pete K. schrieb: > Bedank Dich bei Atmel für den Mist, dass sie es noch nicht geschafft > haben, einen vernüftigen ISP zu designen ... :-) Man muss sich ja nicht immer den DAUs anpassen. Das Fuse-System von Atmel ist jetzt keine Rocket Science, auch wenn alle Anfänger grundsätzlich drüber stolpern. Muss ja nicht ALLES Deppengerecht wie Arduino sein.
cyblord ---- schrieb: > auch wenn alle Anfänger > grundsätzlich drüber stolpern. Muss ja nicht ALLES Deppengerecht wie > Arduino sein. Und warum nicht? Muss es kompliziert sein, dass sich einige Wichtigtuer hier im Forum profilieren können? Der Fusekram ist veraltert und nicht mehr zeitgemäß.
Hi >Und warum nicht? Muss es kompliziert sein, dass sich einige Wichtigtuer >hier im Forum profilieren können? >Der Fusekram ist veraltert und nicht mehr zeitgemäß. In der Industrie kann man ganz gut dami leben. Wen interessieren ein paar Amateure? MfG Spess
spess53 schrieb: > In der Industrie kann man ganz gut dami leben. Na klar, wenn da so ein paar verbohrte Typen im Entwicklungsteam sitzen. Wie soll sich etwas ändern? ;-> Du kannst deinen Platz als Held der AVRs solange verteidigen, bis einer mit etwas neuem kommt. Und der kommt ganz bestimmt! ARMer spess. Helden gab es zum Beispiel für den 517(A) und seine Verwandten, die 68HC, ... Heute schreit keinn Hahn mehr danach.
no Fuses schrieb: > Helden gab es zum Beispiel für den 517(A) und seine Verwandten, die > 68HC, ... Heute schreit keinn Hahn mehr danach. Für Dich werden die Teletubbies-Fuses eingeführt, da gibt's dann ein Nochmal, Nochmal, wenn's beim ersten Mal nicht klappt. Professionellere Anwender hingegen werden mit dem durchaus nützlichen System der Fuses weiterhin klarkommen und damit den Controller den Erfordernissen anpassen. Dass sich Bastler immer mal wieder aussperren ist vernachlässigter, zudem tritt aus Kostengründen der Lerneffekt recht schnell ein. Und wenn's jemand trotz allgemein gut verfügbarer Information öfters verpeilt, so gibt's immer ein anderes und besser geeignetes Hobby.
MWS schrieb: > Für Dich werden die Teletubbies-Fuses eingeführt, da gibt's dann ein > Nochmal, Nochmal, wenn's beim ersten Mal nicht klappt. Nö, für mich gibt es gar keine Fuses. Die notwendigen Einstellungen sind Teil des Programms. Ist doch logisch, oder? Möchtest du den Stack auch fusen? :-P
no Fuses schrieb: > Ist doch logisch, oder? Entscheidend ist nicht, was für Dich logisch erscheint, sondern was für den Hauptanwender, die Industrie nützlich ist. Nützlich ist dort etwas, das als Einheit sicher funktioniert und vom Kostenfaktor günstig ist. Fuses scheinen in diesem Zusammenhang nicht so schlecht abgeschnitten zu haben, sonst gäb' es sie längst nicht mehr. Der Nutzen als Einheit entscheidet, darum gibt's externe Bausteine in Form eines BIOS für x86er, die man für einen uC mit ein paar kB Flash als völlig inakzeptabel empfände. > Möchtest du den Stack auch fusen? :-P Was hat denn ein dynamisch genutzter Speicherbereich wie ein Stack mit einer statischen Konfiguration zu tun? Kann's denn sein, dass Du gar keine Ahnung hast und hier nur was Lustiges schreiben wolltest?
MWS schrieb: > Fuses scheinen in diesem Zusammenhang nicht so schlecht abgeschnitten zu > haben, sonst gäb' es sie längst nicht mehr. Es gab auch Lochkarten, in der Industrie, lange, sehr lange. Und: no Fuses schrieb: > Na klar, wenn da so ein paar verbohrte Typen im Entwicklungsteam sitzen. > Wie soll sich etwas ändern? ;-> MWS schrieb: > ein Stack mit > einer statischen Konfiguration zu tun? ??? Lage des Stack, Speichersegmente, ... stehen zur Übersetzungszeit fest. MWS schrieb: > und vom Kostenfaktor günstig ist. Die Fuses in einer extra Datei zu archivieren und spezielle Tools vorzuhalten ist nicht kostengünstiger, als ein paar Zeilen im Quellcode, oder? Aber anstatt nur zu schreiben, dass Fuses nicht schlimm sind, solltest du die großen Vorteile nennen.
no Fuses schrieb: > cyblord ---- schrieb: >> auch wenn alle Anfänger >> grundsätzlich drüber stolpern. Muss ja nicht ALLES Deppengerecht wie >> Arduino sein. > > Und warum nicht? Muss es kompliziert sein, dass sich einige Wichtigtuer > hier im Forum profilieren können? > > Der Fusekram ist veraltert und nicht mehr zeitgemäß. Ja muss es, denn wenn ich mal so weit bin, dass ich das alles mit Links kann, dann will ich auch sagen können: "Läppisch!" ;-)
MWS schrieb: > no Fuses schrieb: >> Helden gab es zum Beispiel für den 517(A) und seine Verwandten, die >> 68HC, ... Heute schreit keinn Hahn mehr danach. > > Für Dich werden die Teletubbies-Fuses eingeführt, da gibt's dann ein > Nochmal, Nochmal, wenn's beim ersten Mal nicht klappt. Professionellere > Anwender hingegen werden mit dem durchaus nützlichen System der Fuses > weiterhin klarkommen und damit den Controller den Erfordernissen > anpassen. > > Dass sich Bastler immer mal wieder aussperren ist vernachlässigter, > zudem tritt aus Kostengründen der Lerneffekt recht schnell ein. Und > wenn's jemand trotz allgemein gut verfügbarer Information öfters > verpeilt, so gibt's immer ein anderes und besser geeignetes Hobby. Ich finde das auch sehr nützlich und (!) lehrreich war das erste Aussperren auch. Was allerdings das Studio betrifft, da kannst du dich auch aussperren ohne Fuses. Ich komme nie aus dem DW Modus raus und muss dazu immer HV gebrauchen, um das wieder auszustellen. Braucht nun keiner was dazu zu sagen. Anfangs dachte ich die Probleme kommen vom lahmen Netbook, aber mittlerweile habe ich ein Ultrabook und da komme ich auch nicht wieder raus. Macht aber nichts, hab zwei Dragon und der eine hat dann HV drauf, der andere ISP.
no Fuses schrieb: > Lage des Stack, Speichersegmente, ... stehen zur Übersetzungszeit fest. Hmm, Du scheinst nichts von dynamisch genutztem Speicher vernommen zu haben.. Stack ist RAM, die Größe abhängig vom Programmablauf und anfallenden Daten, da würd' ich doch mal gern sehen, wie Du den Stack fusen möchtest. > Aber anstatt nur zu schreiben, dass Fuses nicht schlimm sind, solltest du die großen > Vorteile nennen. Sie sind aus dem Programm, und z.B. über Bootloader heraus nicht änderbar, um nur ein Beispiel zu nennen. Das ist ein nicht zu unterschätzendes Sicherheitsmerkmal. Und wie ich schon schrieb, der Nutzen als Einheit macht's, der Anwender und sein Einsatzzweck entscheidet über den Nutzen. Nur glaub' ich nicht, dass dies mit Dir und Deinen durchaus eigenartigen Ansichten, s.o., überhaupt Sinn macht, darüber zu diskutieren.
F. Fo schrieb: > denn wenn ich mal so weit bin Nein, nein, die AVRs sind doch nur für die tollsten Profis! In den letzten Jahren konnte man das schön auf der embedded world sehen. Der ATMEL Stand wurde von den Hobby Bastlern belagert. Echte Gespräche waren schwer bis unmöglich. Und diese Jahr? Keine AVRs (vielleicht gab es irgendwo eine kleine Ecke), keine Hobby Bastler, nur ARM und echte Produktmanager als Gesprächspartner. Mal sehen, was 2014 bringt. ;-D
Diese Diskussion taucht ja immer wieder auf und es kommt auf den Standpunkt an. Vielleicht braucht jemand einen veränderbaren Takt und ist froh, wenn er den im Programm ändern kann. Ich persönlich finde es ganz hervorragend, dass genau diese Einstellungen fest eingestellt werden können, nicht in den Code hauen und somit eine feste Größe bilden. Auf jeden Fall steht etwas fest: Wenn Atmel immer noch daran fest hält, dann denken die sich sicher etwas dabei. Ich sehe das immer aus Sicht des Technikers. Den festen Takt über Quarz oder interner Takt über Fuses geregelt, gibt mir eine feste Messgröße.
MWS schrieb: > Stack ist RAM, die Größe abhängig vom Programmablauf und anfallenden > Daten, da würd' ich doch mal gern sehen, Klar, der wird dynamisch angefordert, mit new(), oder? Er liegt irgendwo im Speicher, keiner weiss wo, er fängt irgendwo an, kann beliebig groß werden, das ergibt sich einfach so, oder? MWS schrieb: > Sie sind aus dem Programm, und z.B. über Bootloader heraus nicht > änderbar, um nur ein Beispiel zu nennen. Das ist ein nicht zu > unterschätzendes Sicherheitsmerkmal. Soll doch einer über den Bootloader das Clocksystem umkonfigurieren, wo ist das Problem? Das einzige Sicherheitsmerkmal ist das Auslesen der Programmspeicher zu verhindern. Und das können alle moderenen Chips.
F. Fo schrieb: > Den festen Takt über Quarz > oder interner Takt über Fuses geregelt, gibt mir eine feste Messgröße. Du traust deinem eigenen Code nicht. Du brauchst mehr Selbstbewusstsein und keine Fuses. Wenn du den Timer falsch konfigurierst, sind deine Zeiten auch im A...bfall.
no Fuses schrieb: > F. Fo schrieb: >> Den festen Takt über Quarz >> oder interner Takt über Fuses geregelt, gibt mir eine feste Messgröße. > > Du traust deinem eigenen Code nicht. Du brauchst mehr Selbstbewusstsein > und keine Fuses. Wenn du den Timer falsch konfigurierst, sind deine > Zeiten auch im A...bfall. Klar traue ich meinem eigenen Code (noch) nicht. Weil ich gerade mit C angefangen habe. Da bin ich froh, wenn ich mich auf was Festes beziehen kann. Außerdem ist es auch für Service Zwecke ganz gut. Wenn ich da was messen will und eine Bezugsgröße habe, kann ich ab da schon mal auf der sicheren Seite sein und muss mir keine Gedanken übers Programm machen und überlegen, ob die Daten durch den falschen Takt verloren gehen.
no Fuses schrieb: > Klar, der wird dynamisch angefordert, mit new(), oder? Er liegt irgendwo > im Speicher, keiner weiss wo, er fängt irgendwo an, kann beliebig groß > werden, das ergibt sich einfach so, oder? Sei mir mal nicht bös, aber aus Deinem Geschreibsel lese ich heraus, dass Du wirklich keinerlei Ahnung hast. Du wirst verzeihen, dass ich aus "Kompatibilitätsgründen" jegliche weitere Diskussion mit Dir einstelle.
F. Fo schrieb: > Klar traue ich meinem eigenen Code (noch) nicht. Aber deinen Fuses Einstellungen? MWS schrieb: > dass ich aus > "Kompatibilitätsgründen" jegliche weitere Diskussion mit Dir einstelle. Tja, dir fällt also auch kein Pro für Fuses ein.
no Fuses schrieb: > Tja, dir fällt also auch kein Pro für Fuses ein. Ein Pro nannte ich doch bereits, bemühe Dich doch wenigstens zu verstehen. Und nein, mein letzter Post war nur der freundliche Hinweis darauf, dass es mir zu blöd ist mit jemandem zu diskutieren, der offensichtlich keine Ahnung zum Thema hat. Soll ich mich also mit jemand über LEDs unterhalten, der nicht mal weiß, wie 'ne Glühbirne funktioniert? LOL
no Fuses schrieb: > F. Fo schrieb: >> Klar traue ich meinem eigenen Code (noch) nicht. > > Aber deinen Fuses Einstellungen? Ja, warum auch nicht? Nach dem anfänglichen zu schwunghaften Vorgehen und einigen verfuseden Controllern, da liest man dann doch erst mal und weiß wie es geht. Aber ich finde es eigentlich blöd drüber zu streiten. Sicher haben beide Systeme ihre Berechtigung und auch Vorteile wie Nachteile. Drum lasst uns in Frieden schlafen gehen und beide Lager schauen sich mal unvoreingenommen das andere System an. Es ist doch so, wenn man sich mit einem System gut auskennt, die Kosten nicht zu hoch sind, dann bleibt man möglichst dabei und nur weil es dadurch einfacher wird. Aber letztendlich soll so ein µC eine Aufgabe erledigen und da muss ich irgendwann das nehmen, was für die Aufgabe das Beste und vielleicht das günstigste System ist. Somit habe ich dann wieder alle Vor- und Nachteile hin zu nehmen. Hier gibt es genauso die Diskussion über µC oder NE555, eben auch solche Lager. Die Hardwarefraktion gibt gute Gründe für ihre Entscheidung an, die Softwarefraktion ebenso. Zu welchem Lager es einen zieht, das ist dann doch nur noch Geschmackssache.
MWS schrieb: > dass > es mir zu blöd ist mit jemandem zu diskutieren So in der Art schriebst du schon, und doch läßt es dich nicht in Ruhe? Innovation ist nicht dein Ding? "Es war schon immer so, dann muss man es nicht ändern." Es gibt kein Pro für den fehlerträchtigen Fusekram, oder? MWS schrieb: > darum gibt's externe Bausteine in > Form eines BIOS für x86er, die man für einen uC mit ein paar kB Flash > als völlig inakzeptabel empfände. Und bei µC und CPU reicht dein Horizont nur von AT90 bis ATMega. x86 gehört zumindest nicht dazu. Ach ja, Fuses haben x86 auch nicht. ;-P
Thread beobachten
Seitenaufteilung abschaltenBitte 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.