Ponyprog: Wozu das Verifying??

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.

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

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

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?

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