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
to verify = überprüfen Pony überprüft, ob das Schreiben auch geklappt hat.
>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 :)
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.
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
Ich progge meine AVR's jetzt nur noch mit YAAP, weil es viel, vieeelllll schneller und bequemer die Daten brennt.
Das Veryfy soll auch porüfen ob ggf auf der Strecvke PC --> Programmerkabel --> AVR was futch gegangen ist.
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...
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
@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.
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
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.
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
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....
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?
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.
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
Hab noch mit AVRProg getestet, aber das bringt dieselben Fehler. Hat wohl doch der Controller nen Hau....
Neuer Controller drin, aber die gleichen Probleme. Weiß jemand Rat?
Irosenhagen wrote: > Neuer Controller drin, aber die gleichen Probleme. > Weiß jemand Rat? Dann solltest Du vielleicht doch mal die Programmierleitungen durchmessen...
Die Auflösung war nen Wackelkontakt in einem Wannenstecker. Aber bis man das gefunden hat...
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.