www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMega: Wie oft kann man die Fuse Bits programmieren?


Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

weiß jemand, wie oft man die Fusebits programmieren kann?

Sind die als Flash (10000 mal) oder als EEPROM (100000 mal)
implementiert?


Danke

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie oft willst Du die Fuses umprogrammieren?
Alleine für 10000 mal brauchst Du Jahre und nach 20 mal umprogrammieren
sollte man das für sich richtige mit den Fuses eingestellt haben wo bei
man meist nur den Takt, Taktquelle und evtl. noch die Bootsize
einstellt.

Gruß
Andi

Autor: Thomas Burkhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube mich entfernt zu erinnern, dass die Fuses FLASH sind...
Mangels Beweis allerdings ohne Garantie ;)

Die Frage bleibt, warum du die Fuses zehntausend mal umstellen willst.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Frage lässt sich leicht leicht beantworten.

Ich entwerfe gerade einen Programmer für PIC/AVR controller.

Und bei den ATmega ist es nun mal so, dass die
Programmier/Lesegeschwindigkeit im Verhältnis zum Takt steht.
Programmingclock >= 2x oder 3x CPU clock.

Da der Controller interne 8MHz hat, wäre is durchaus interessant vor
jedem SW-Update auf intern 8MHz umzustellen und nach der Programmierung
zurück auf die vom User gewünschte Taktzahl.

Habe gerade mal einige Zeitmessungen mit einem ATmega64 (64kBytes
Flash)gemacht.
Verify-Zeit bei 1MHz ca. 9s
Verify-Zeit bei 8Mhz ca. 2s

Und gerade wenn man selber programmiert und sein Programm öfter mal
update will (z.B. beim Debuggen), wären da pro Update bestimmt 15s
Zeitersparnis drin, die die Nerven des Programmieres schonen.

Wenn man mal einen Tag lang programmiert und seine SW so 100mal und
öfter zum Prozessor hochläd, hat man bestimmt eine halbe Stunde
Freizeit gewonnen. Vielleicht auch mehr.  So leicht kann die Antwort
sein :-)

Die andere Alternative wäre, man Taktet seinen Prozessor immer mit min.
8MHz und braucht die Fuses dann nicht umzustellen. Ansonsten wären es
zwei updates pro Programmierung (intern 8MHz und dann das gewählte).



Bernd

Autor: Thomas Burkhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ok :)

Diese zehn Sekunden kannst du aber auch bequem dazu benutzen mal die
Augen auszuruhen oder den Rücken zu entspannen g

Naja, bei 100 Updates pro Tag kommt man immernoch auf 100
(Arbeits)Tage, also ein halbes Jahr. Vielleicht stirbt der µC dann
ohnehin ob irgendeines anderen "Unfalls".

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du jedes mal den Clock vor und nach dem Proggen umstellen willst
gehen dafür die 7 Sekunden auch drauf.
Genau genommen sparst Du Dir im Höchstfall bei 100 mal proggen 11,67
Minuten wenn das Umstellen der Fuses vor und nach dem Proggen
automatisch mit umgestellt wird wobei das bestimmt auch ne Sekunde
dauert.
Allerdings konnte ich das mit Pony-Prog und nen Mega8515 nicht
nachvollziehen.
Bei 1MHz sowohl auch bei 8MHz war die Zeit zum Proggen und Verify
identisch.
Möglich, dass das mit nen STK500 anders ist.
Keine Ahnung, mit was Du proggst aber vielleicht solltest Du Dir vor
jedem proggen Deine Erweiterungen genauer durchdenken und kontrollieren
um die Anzahl der Updates zu verringern.
Durch ein genaueres Durchdenken des Programmes im Vorfeld kann man auch
schneller zum Ziel kommen.

Gruß
Andi

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wenn man mal einen Tag lang programmiert und seine SW so 100mal und
öfter zum Prozessor hochläd,..."

Vielleicht sollte man da eher mal grundsätzlich über die
Herangehensweise an die Programmierung nachdenken.

Die Programmierung scheint heute fast ausschließlich nach dem
"Versuch/Fehler"-Prinzip abzulaufen. Mal eben zwei Zeilen ändern und
gucken was passiert. Länger über ein Problem nachdenken, Entwerfen und
dann Umsetzen scheint aus der Mode gekommen zu sein.

Zu meinen Zeiten am Großrechner wäre das undenkbar gewesen. Mal eben
alle Karten neu ablochen und dem Operator und die Hand drücken, der
hätte mir eine Vodel gezeigt :-)

Gruß
Ingo

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ganz kann ich mich dem Argument von Ingo nicht verschließen...
Aber:
Wenn ich etwas neues ausprobiere, z.B. irgendeinen exotischen
Timermodus, dann gehe ich auch gerne nach diesem Modell vor. Zwar mache
ich mir auch zuerst Gedanken, was das Programm eigentlich machen soll,
aber manchmal gehts halt einfacher mit der try 'n error Methode.
Bei komplizierteren Geschichten habe ich den Simulator sehr schätzen
gelernt. Leider kann er z.B. die TWI-Schnittstelle nicht simulieren...

Aber mal im ernst: Wer flasht seinen Controller 100x pro Tag? Und
selbst wenn, dann hat der Controller nach dieser Frist die 3 Euro
verdient, die er gekostet hat.

Autor: bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War ja auch nur ein extrem Beispiel. Wenn man davon ausgeht, dass von
den 64k warscheinlich nur 1-8k real genutzt werden, dann geht es
sowieso schneller.

@Andi: Das umsetzen der Fuse dauert ca. 10ms. Was die
Programmiergeschwindingkeit angeht, bedeutet 8MHz Clock nicht
automatisch, dass es schneller geht. Es bedeutet nur, dass der
Controller die Daten schneller aufnehmen kann, ausgeben kann. Wenn der
Programmer es nicht unterstützt, hat es keine Bedeutung.

@Ingo: Wenn immer möglich verwende ich auch den Simulator, aber es gibt
eine Vielzahl von Anwendungen, wo ein Debuggen im Simulator quasi
unmöglich ist und da macht es schon Sinn. Wozu gibt es sonst
In-Circuit-Debugger? Wenn dann auch noch externe Komponenten im Spiel
sind, die dem Controller das Timing vorgeben, bleibt nur die
Echtzeitausführung in Verbindung mit Trace Messages um Fehler zu
suchen. Und wenn man keinen ICD besitzt, bleibt nur die Möglichkeit den
Programmfluss irgendwo zu stoppen und zu schauen, wie weit alles nach
Plan gelaufen ist. Wenn alles OK war, lässt man das Programm beim
nächsten Start ein Stückchen weiter laufen. Hier ist aber ohne ICD
jedesmal eine Neuprogrammierung für erforderlich.


An alle: Kann mir jemand sagen, wie lange PonyProg zur
Programmierung/Verifizierung eines ATMega mit 8, 16, 32, 64k braucht?
Was ist die niedrigste Taktung des ATMega, bei der PonyProg noch
funktioniert?
Und was macht Ihr, wenn als Clocksource der Low-Frequency Oszillator
angewäht wurde? Auch hier gilt, 1 Programmingcycle = 2 Oszillatorcycls.
Ich glaube bei einem 32kHz Oszillator könnte man da getrost in den
Urlaub fahren. Hier ist man immer gezwungen, die Clock umzustellen.

Gruß,
Bernd

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd!

Ich finde die Idee mit den Fuses umstellen nicht schlecht, aber dennoch
für sehr umständlich.
Man muss bedenken, dass jeder Prozessor andere Fuses besitzt. Manche
Prozessoren haben gar keine Fuses.
Oder der ATmega48V/88V/168V kann nur im Bereich von 0 - 6MHZ betrieben
werden.
Wenn du mit deinem Programm sowieso nicht alle Prozessoren abdecken
möchtest kann man das ruhig so machen.
Aber wenn ich mir deine Erzählung durchlese, sehe ich, dass du auch
Pics programmieren möchtest, was mir zeigt, dass du ein Interesse daran
hast, möglichst viele Prozessoren abzudecken.
Mein Ratschlag:
Entwerfe dein Programm so, dass du die Geschwindigkeit in MHZ für den
Zielprozessors angeben kannst. Danach wird die höchstmögliche
SPI-Geschwindigkeit laut Datenblatt berechnet, die übrigens auch wieder
von Prozessor zu Prozessor schwanken kann (Beispiel AT90S1200 benötigt
wieder eine andere SPI-Geschwindigkeit).

Ich habe auch ein paar Fragen:
2 Sekunden Verifizierung (ATMEGA64) sind für ein Programmiergerät
ungeheuer schnell. Liest du bei der Verifizierung den gesamten
Flash-Speicher aus?

Aus Welcher Hardware besteht dein neues Programiergerät? Welcher µC?
Welche Programmierprache bzw. Compiler wird für die PC-Plattform
verwendet? Welches Protokoll verwendest du für die Übertragung an das
Programmiergerät für die AVRs?

Ich würde mich sehr freuen, wenn du uns Näheres darüber berichtest.

Danke

Tschüss

Martin

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

2s sind nicht weiter exotisch. Bei entsprechendem SPI-Takt und
schneller PC Übertragung ist das keine Thema.

Matthias

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja schon.
Aber das Programmiergerät enthält ja sicherlich einen µC, der die Daten
für die SPI-Schnittstelle aufbereiten muss. Wenn man nicht aufpasst, hat
man hier einen Flaschenhals. Der Kontroller muss die Daten holen, das
Zielsystem damit programmieren und die Daten wieder zurückschicken.

Martin

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ein AVR der mit 8MHz läuft hat bei 2MHz SPI-Takt 32 Takte Zeit um das
nächste Byte für die SPI Schnittstelle bereitzustellen. Das sollte
locker reichen. Man arbeitet dann eben mit entsprechend großen Puffern
und FIFO's. Die reine SPI-Übertragungszeit beträgt etwa 1s. Man hat
dann noch eine ganze Sekunde Zeit die Daten in den PC zu schaufeln. Per
USB kein Problem. Been there. Done that.

Matthias

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Martin:
"2 Sekunden Verifizierung (ATMEGA64) sind für ein Programmiergerät
ungeheuer schnell. Liest du bei der Verifizierung den gesamten
Flash-Speicher aus?"
Antwort: Ja. Darüber hinaus habe ich noch einen Read-Mode, der nur die
Programmierten Bytes ließt, dann geht es abhängig von der Programmgröße
entsprechend schneller.

"Aus Welcher Hardware besteht dein neues Programiergerät? Welcher
µC?"
FT232BM (USB-Controller) & PIC18F242@40MHz (ca. 10 Millionen
Befehle/Sek.). 12V generierung inkusive. Es ist kein externes Netzteil
erforderlich. Preis für die Bauteile werden ca. bei 15€ (Reichelt)
liegen.
Der PIC lässt sich direkt in der Schaltung über den USB-Controller
programmieren, so dass für Firmwareupdates kein extra Programmiergerät
erforderlich ist. Für PIC18Fxx2 lässt sich die Schaltung also auch ohne
µC verwenden, was allerdings deutliche Geschwindigkeitseinbußen zur
folge hat.
"Welche Programmierprache bzw. Compiler wird für die PC-Plattform
verwendet?" C++
"Welches Protokoll verwendest du für die Übertragung an das
Programmiergerät für die AVRs?" Nichts genormtes/Möglichst wenig
Overhead.

Und falls es interessiert:

Geplante Unterstützung für:
PIC18Fxx2/8 (Programmier-/Verifizierzeit PIC18F252 ca. 2,5s ohne EEPROM
- EEPROM ca. +1s) (weitere PIC18Fxxxx werden wohl folgen)

ATmega Serie (ATmega64 mit 64k Programmieren/Verifizieren @>6,7MHz ca.
5s ohne EEPROM)

PIC12F629/675 und kompatieble PIC16F????

ATtiny 11/12 (ca 1-2Sek)

Die Programmierzeiten verkürzen sich, wenn der Speicher nicht komplett
gefüllt ist.

Bernd

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.