Fuses ATMega1284P

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

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

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:
> 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

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:
> 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

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