www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Vergleich bei PonyProg abschalten


Autor: Niko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

gibt es einen Möglichkeit bei PonyProg den Vergleich der Daten nach dem
Schreiben abzustellen?

Das dauert beim Atmega128 ja Ewigkeiten bis der fertig is.

Gruß

Niko

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

nicht das ich wüßte. avrdude verwenden. Das verifiziert nur was auch
verifiziert werden muß.

Matthias

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar geht das!
Guckst Du in der Datei "PONYPROG2000.ini".
Da suchst Du den Eintrag "VerifyAfterWrite" und setzt ihn auf
"=NO".
Das geht in der Version 2.06c bei "Write Flash", "Write EEPROM" und
"Write all", wobei man "Write all" erst nach dem lesen der Fuses
machen sollte weil die mitgeschrieben werden.
Bei dem Comando "Program" geht das leider nicht. Dann beim Verify
einfach auf "Abort" klicken.
Willst Du Flash und EEPROM schreiben, dann mit den Einzel-Comandos
"Write Flash" und "Write EEPROM".

Wegen dem Tempo, hast Du in der .ini den Eintrag "SPIBusSpeed" auf
"FAST" oder sogar "TURBO" eingestellt, im "I/O port setup" auf
"SI Prog I/O" (seriell) oder "AVR ISP I/O" (parallel) gestellt und,
wenn mit Windows 2000/XP, einen Treiber zum direkten Zugriff der
I/O-Ports installiert?

MfG
Andi

Autor: Niko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank erstmal für deine Antwort.

"SPIBusSpeed" steht auf NORMAL. Der IO-Port steht auf "AVR ISP
I/O".
Schade das man beim Commando "Program" das Vergleichen nicht
abstellen kann.

Ich werd mal mit der .ini ein wenig ausprobieren.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi

...hab's auch ausprobiert und

"VerifyAfterWrite=NO" gesetzt.

Geht viel schneller. Sehr guter Tipp von Dir!!!!!

Man muss sich nur daran gewöhnen, die Fuse-Bits vorher auszulesen ;-)

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vorsicht !!!

Wer viel mit dem ATmega8 arbeitet, sollte diese Option aber nicht
nutzen.

Hab mir gerade mein RESET-PIN versehentlich weg-ge-FUST  :(

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kam es denn dazu, welche Option meinst Du, das Verify=NO etwa?
Laut Deinem Bild von Pony-Prog ist das RSTDISBL für den User gespeert.

MfG
Andi

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mir gerade den Mega8 im Pony-Prog angesehen und jetzt ist der
Groschen gefallen.
Ist ja deshalb gespeert, weil Du es jetzt nicht mehr zurück stellen
kannst, logisch.
Aber das kann doch nicht vom "VerifyAfterWrite=NO" kommen.

MfG
Andi

Autor: kryon200_0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst ja bei Verify einfach auf Abbrechen klicken.......

Autor: Daniel Braun (khani)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal eine Anmerkung zum Thema :

Warum wollt Ihr immer das verify abschalten - nur weil es ein paar
Sekunden länger dauert ?! Das Verify kostet nichts, es beschädigt den
chip nicht oder macht sonst irgendetwas schlimmes.

Es dient einfach der Sicherheit, dass auch wirklich alles auf dem chip
gelandet ist, was man dort haben will und sich keine anderen
Informationen durch Übertragungsfehler eingeschlichen haben.

Eigentlich sollte das Programmieren eines Chips 5 mal so lange dauern.
Dann würden die meisten Leute viel bessere Programme schreiben. Ich
merke das schon bei mir selbst - bei meiner Diplomarbeit hatte ich
Board mit einem C167 bei dem das Programmieren über den (nicht von mir
geschriebenen) Bootloader ca 4 Minuten gedauert hat. Da üebrlegt man
sich schon genau, was man tippt und kompiliert, bevor man es in den
chip hämmert. Trial and error ist kein Programmierstil, sondern
Kinderkram. Erst denken, dann tippen, dann denken und erst dann
kompilieren, noch mal denken und ganz am Schluss das Programm in den
Mikrocontroller schreiben (vorher ggf noch simulieren).

MfG, Daniel

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, kommt ganz drauf an, was man macht.
Hat man nun eine neue Routine geschrieben, klar, erst mal vorher 3 mal
drüber gucken und im Kopf nachvollziehen, obs passt, dann flashen und
Verify komplett durchziehen um sicher zu sein, das ein Fehler in der
neuen Routine nicht beim Flashen passiert sein kann.
Aber bei "Trial und siehts gut aus" (LCD-Darstellung) habe ich
einfach keine Geduld, das Verify abzuwarten da man ja zum Beispiel nur
Werte für irgend eine Darstellung auf einem GLCD verändert wobei ich
mir dann auch sicher bin, das die Routinen alle funtzen.

MfG
Andi

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.