mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ponyprog: Wozu das Verifying??


Autor: Michael Brinkman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich programmiere meinen Atmega mit Ponyprog, jedesmal nach dem schreiben 
führt das Programm ein Verifying durch. Wozu dient das, wenn ich auf 
abbrechen drücke ist trotzdem alles im Controller was drin sein soll. 
Ist es für den Controller schädlich wenn ich wärend des Verifyings 
abbreche?

Gruß
Michael

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
to verify = überprüfen

Pony überprüft, ob das Schreiben auch geklappt hat.


Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

>Ist es für den Controller schädlich wenn ich wärend des Verifyings
>abbreche?

nein, ist es nicht.

Ich breche immer ab, vorallem bei Testversionen, um Zeit zu sparen :)

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Grunde sind es 3 Schritte zum programmieren eines uC:

1.Chip erase (löschen)
2.programmieren
3.Verify (auslesen und mit den zu programmierenden Daten vergleichen)

Punkt 1 kann man für UNGENUTZTE Speicherbereiche weglassen,ist aber 
defininitiv nicht Empfehlenswert für Speicherbereiche die in irgendeiner 
Weise verwendet werden.Punkt 3 ist nur notwendig,wenn der Chip dann in 
die finale Verkaufsversion eingesetzt wird.Oder wenn beim debuggen 
Speicherfehler auftauchen.Da Flashspeicher nur eine begrenzte 
Lebensdauer haben (einige 10.000 male beschreiben,bei neueren auch 
einige 100.000 bis 1.000.000 male) ist das dann eine Hilfe um 
Fehler/Ermüdungen im Flash zu finden.Weiterhin ist Verify gut um die 
Kommunikation mit der Zielhardware zu überprüfen.

Manche Entwicklungsumgebungen (z.B. KEIL-Tools) erlauben es 
auch,auszuwählen welche der 3 Schritte beim Programmiervorgang wirklich 
ausgeführt werden.

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der INI-Datei von Ponyprog steht unter anderem:

VerifyAfterWrite=YES

Einfach "NO" hinter das Gleichheitszeichen, und der Spuk ist vorbei ;-)

Und wenn Du schon mal da bist, lohnt sich auch ein Versuch, die

SPIBusSpeed=NORMAL

auf FAST umzustellen...

Gruß Johannes

Autor: Metaller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich progge meine AVR's jetzt nur noch mit YAAP, weil es viel, vieeelllll 
schneller und bequemer die Daten brennt.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Veryfy soll auch porüfen ob ggf auf der Strecvke PC --> 
Programmerkabel --> AVR was futch gegangen ist.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab das verify wieder reingenommen, weil ich mal 'nen problem mit 
meinem kabel hatte. das war nicht richtig zusammengekrimpt und hat dann 
irgendwie die daten nicht immer richtig übertragen. wenn man dann auf 
fehlersuche in korrektem code geht, dann ist das ganz schön 
frustrierend.
An sonsten kann man mehr zeit einsparen, wenn man das prinzip 
"nachdenken-programmieren-noch mal nachdenken-auf avr übertragen" 
befolgt. programmieren-übertragen-nachdenken ist auf dauer nicht immer 
effektiv, auch wenn die verlockung groß ist...

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, Metaller, Läubi und Martin, aber ihr habt offenbar noch nie das 
SI von Lancos probiert, das im Vergleich zu dem komischen 
Kanda-Parallelport-Dongle einfach nur gnadenlos zuverlässig ist. Ich 
habe es seit Jahren professionell in Gebrauch, damit wurden inzwischen 
diverse Tausend unterschiedlichste AVRs problemlos für die Produktion 
programmiert, und alle Malesche, die ich damit je hatte, waren klar auf 
nicht SPI-konforme Benutzung der betroffenen Pins durch die jeweilige 
Anwendung zurückzuführen. Z.B. dass die MOSI- und MISO-Pins nach dem ISP 
zu einer Tastaturabfrage herangezogen wurden...

Und YAAP? Mag ok sein, wenn man mit dem mega8 als dem modernsten 
unterstützten AVR zufrieden ist. Aber ich brauche dummerweise auch mal 
einen mega16, die megaX8, einen mega128, tiny2313 oder -X5, von denen 
YAAP noch überhaupt nichts gehört hat.

Und noch ein "Schmankerl": Ich bekam das Kando-Dongle jüngst zusammen 
mit einem Kanda-Handheld-Programmer wieder auf den Tisch. Und im 
Handbuch stand der freundliche Hinweis, dass das Teil unbedingt direkt 
an den Rechnerport anzustöpseln und unbedingt das mitgelieferte Kabel 
vom Dongle zum Programmer zu verwenden sei - und dass ich den 
Extra-Stecker des Kabels auch zum ISP meiner Anwendung mittels des 
Kanda-AVR-ISP verwenden könnte. Allerdings müsste ich da schon das 
Originalkabel verwenden, sonst könne die  richtige Funktion nicht 
garantiert werden.

Echt Spitzenklasse! Das Kabel ist so kurz, dass ich mal gerade den 
Handheld-Programmer noch vernünftig anstöpseln kann, ohne gleich 
"Turnübungen" machen zu müssen, aber meine Prototypen jedesmal vom 
Labortisch zum Entwicklungs-PC zu tragen, der auf dem Fußboden steht, 
und wieder zurück, weil ich da unten nicht vernünftig messen kann, finde 
ich doch etwas zu viel verlangt.

Da lob ich mir doch mein (auf AVR-only minimiertes) Pony-SI, das völlig 
problemlos auch ein 5m-Standard-9pol-Modemkabel zum PC wegsteckt...

Gruß Johannes

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Johannes: Ich benutz eh kein Ponyprog, es war nur ein Hinweis warum ein 
Verify nötig sein kann, das macht man nicht nur beim AVR Programmieren, 
sodnern Nero bietet z.B: auch die Option an die gebrannten Daten nach 
dem brenne mit dem Orginal zu vergleichen, wenns auf jeden Bitfehler 
ankommt mag das sinnvoll sein.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Johannes A:

prinzipiell hast Du recht, nur geht es ja nicht immer gleich um tausende 
AVR und Produktion.

Was aber auch und gerade für die üblichen Privat-Basteleien wirklich 
betont werden sollte, ist dieser Satz:

"Und im Handbuch stand der freundliche Hinweis, dass das Teil unbedingt 
direkt an den Rechnerport anzustöpseln und unbedingt das mitgelieferte 
Kabel vom Dongle zum Programmer zu verwenden sei."

Alle Parallelport-Programmer mit IC sollten direkt an den Port gesteckt 
werden. Die benutzten ICs (74HC125, 74HC244 o.ä.) sind keine 
Leitungstreiber. Das Kabel vom Programmer zur Schaltung hat die 10 Adern 
als Flachbandkabel, weil so jede 2. GND ist und das Übersprechen 
reduziert wird.
Ich habe mit dem Kanda (Original und Nachbauten) noch nie ein Problem 
gehabt. Eine gut geschirmte, voll beschaltete Sub-D-Verlängerung von 1m 
Länge dazwischen geht hier auch, aber eben schon nicht mehr an allen 
Rechnern. Ein ISP-Kabel mit 1,5m Länge geht auch, wenn es im Stück ist 
und die Zusatzlast durch andere Bauteile an den ISP-Pins nicht zu groß 
wird.

Für Einsteiger sollte in den Baubeschreibungen der Programmer auf solche 
Umstände viel mehr hingewiesen werden.

PS: ein myAVR mit 74HC125 von meinem Kollegen war von 3PCs nur an einem 
sehr unzuverlässig zu programmieren, an den anderen beiden garnicht.

Der 74HC125 an einem 1.5m Sub-D-Kabel ist ein extremer 
Unsicherheitsfaktor, sowas macht man nicht, behaupte ich hier mal.

Ich habe dann den 74HC125 runtergschmissen, eine 2x5-Stiftleiste 
raungezaubert und ihm ein Kanda-Dongle zusammengelötet. Läuft jetzt an 
allen 3 PCs mit PonyProg ohne einen einzigen Ausfall...

Gruß aus Berlin
Michael

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze den AVRISP MK II mit einer ISP-Frequenz von 1MHz, 
Programmier- und verifyzeit für einen mega32 sind ca. 2.5 Sekunden! 
Allein das sind mir die 39€ wert! Zuverlässigkeit und bis zu 5m Kabel 
(USB) sind auch perfekt. Support für die neuesten Teile ist kostenlos 
mit dabei.
Zum Thema Verifying:
gerade für Bastler und Prototypen ist das wichtig! Wenn irgendwas die 
Hardware schädigt oder die Prog-Hardware 'wackelig' ist, kann man so 
schon einen Softwarefehler ausschließen. Das kann unter Umständen viele 
Stunden Fehlersuche und graue Haare sparen. Bei der Serienproduktion 
wird der Flash-Speicher sowieso nur 1x beschrieben und das Ergebnis wird 
durch Stichproben geprüft, da kann man sich das Verifying für jeden 
einzelnen µC sparen. Bei NERO habe ich testweise auch mal die Prüfung 
eingeschaltet, das Ergebnis war erschrechend: viele billig-Rohlinge 
brachten im äußeren Bereich Fehler, was bei Datensicherungen extrem 
unangenehm werden kann! Ich lasse deshalb diese Prüfung immer 
eingeschaltet, auch wenn's Zeit kostet.

Autor: Johannes A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist schon immer wieder spannend, wie sich in der weiteren Debatte immer 
wieder herausstellt, wie wenige der Mitdiskutierenden tatsächlich die 
diskutierte Hard- oder Software benutzen...

Damit will ich jetzt nicht sagen, dass Eure Einwände grundsätzlich 
ungerechtfertig sind, nur insofern, dass ich nie behauptet habe, 
grundsätzlich auf Verifying zu verzichten.

Tatsächlich verwende Verifying selber ganz regulär mit Ponyprog in der 
Produktion oder mit Nero oder sonstwas, wo ich jedesmal mit einem neuen 
Target zu tun habe. Denn auch wenn ich mir bei den jeweiligen "Strippen" 
sicher bin, kann ja immer noch das jeweilige Target faul sein.

Nur wenn ich ein und dasselbe Target öfter neu programmiere, und es 
schon einige Male als verlässlich verifiziert ist, schalte ich, und dann 
auch getrost, das Verify ab, um Zeit zu sparen. Und es gibt da in der 
Praxis durchaus Fälle, wo Nachdenken und nochmal Nachdenken und dann 
erst den AVR proggen einfach nicht weiterführt - zuletzt gehabt in einer 
Umgebung mit externen Sensoren, die "manchmal" nicht richtig lief. Ich 
habe da vor Ort so zirka zwei Stunden mit im Nachherein völlig sinnlosem 
Nachdenken über meine Software verbracht, und die Lösung dann binnen 1/4 
Stunde mittels etlicher kleiner Änderungen und ad-hoc Neuprogrammieren 
desselben AVR gefunden: Die tatsächlich verwendeten Sensoren waren 
offenbar andere als die, die mir bei der Entwicklung zur Verfügung 
standen, und brauchten "etwas länger" zu ihrem eigenen Setup - bis dahin 
hatte meine Software allerdings schon auf den geforderten Sensorfehler 
erkannt... Die Lösung brachte dann eine simple extra Warteschleife nach 
dem Init des Controllers. Darauf muss man aber erstmal kommen :-)

@Michael noch:

Das größte Problem mit irgendwelchen HCs vor einem Flachbandkabel ist 
nicht der spezielle Typ, sondern dass diese Teile recht "knallige" 
Signalflanken bringen, die am Ende des Kabels ziemlich viel Verwirrung 
stiften können.

Ein besonderes Problem in diesem Zusammenhang ist, dass die meisten 
Bastlervorschläge heutezutage irgendwelche 6poligen ISP-Anschlüsse ohne 
jeden Pullup außer für RESET haben und nicht darauf hinweisen, dass 
ALLE GND- und VCC-Leitungen angeschlossen werden müssen, damit das 
Ganze soweit zuverlässig funktioniert.

Die "knalligen" Flanken sind dagegen bei einer RS232-Schnitte per se 
nicht vorhanden, und wie gesagt ist die RS232 im Vergleich zum 
Parallelport unbedingt "langkabelsicher".

Gruß Johannes

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

hab gerade nen Problem mit nem ATmega 2561.
Das Flashen geht mittels AVR OSP II problemlos, jedoch übernimmt er 
anscheinend keine Änderungen im Programm.
Also zB laufen Funktionen ab, die ich explizit rausgenommen habe, also 
wäre er nie neu geflasht worden....

Beim Verify hab ich folgende Meldung:

Reading Flash contents...0x0000 TO 0x5413
Comparing Flash data...
Unequal at address 0x0000
Expected 0x0C   Read 0xFF
Leaving programming mode...


Kann das nen Problem sein, wenn direkt das erste Byte vom Flash nen 
Fehler hat?
Lock Bits hab ich schon gecheckt, da ist nichts gesperrt.
Hab nicht wirklich Lust das Teil auszubauen und nen neuen 
reinzusetzen....

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irosenhagen wrote:
> Hey,
>
> hab gerade nen Problem mit nem ATmega 2561.
> Das Flashen geht mittels AVR OSP II problemlos, jedoch übernimmt er
> anscheinend keine Änderungen im Programm.
Dann klappt das Flashen ja offensichtlich doch nicht, oder?

> Also zB laufen Funktionen ab, die ich explizit rausgenommen habe, also
> wäre er nie neu geflasht worden....
Ist er wohl auch nicht!

Aber es braucht schon ein paar mehr Informationen (Programmieradapter, 
Anschlussbelegung).

Abgesehen davon ist es absoluter Schwachsinn, wegen sowas einen alten 
Thread wieder rauszukramen (Zumal der Betreff nichts, aber auch gar 
nichts mit Deinem Problem zu tun hat!). Warum machste nicht einfach 
einen neuen auf?

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab den Thread genommen, weil ich nach Verifying gesucht und damit 
nur exakt 2 Threads gefunden hab.....

Programmieradapter ist einer von www.display3000.com über USB-Adapter am 
Laptop.
Aber den Adapter sowie Verbindung kann ich als Fehlerquelle 
ausschließen, da ich hier noch ein zweites Board mit ATmeag2561 und 
identischer HW hab welches sich astrein flashen lässt.

Hab nochmal nen bisschen rumprobiert und beim fraglichen Controller 
funktioniert auch kein "Erase Device" oder ein programmieren in einen 
anderen Speicherbereich.

Autor: Rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

ich hatte bisher auch immer YAAP genommen, AVR OSP ist ja irgendwo nur 
auf 911er geeicht... seit ein paar Tagen hab ich das hier in der mache 
und es macht nen netten Eindruck:

http://www.myavr.de/download.php?suchwort=DL112

grüße Rene

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab noch mit AVRProg getestet, aber das bringt dieselben Fehler.
Hat wohl doch der Controller nen Hau....

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neuer Controller drin, aber die gleichen Probleme.
Weiß jemand Rat?

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irosenhagen wrote:
> Neuer Controller drin, aber die gleichen Probleme.
> Weiß jemand Rat?
Dann solltest Du vielleicht doch mal die Programmierleitungen 
durchmessen...

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Auflösung war nen Wackelkontakt in einem Wannenstecker.
Aber bis man das gefunden hat...

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.