Detailfrage zu STK500v2 und AVR-ISP, value polling

Johannes F. schrieb:

Daraus geht für mich aber nicht hervor, /auf welche Adresse/ sich das poll1-Byte bezieht, also von welcher genauen Adresse ein Byte zurückgelesen und mit 'poll1' verglichen werden soll. Denn es wird ja mit dem Befehl CMD_PROGRAM_FLASH_ISP bis zu einer ganzen Page gleichzeitig geliefert. Soll das bspw. die erste Adresse sein, die per CMD_LOAD_ADDRESS übertragen wurde, oder die letzte Adresse der geladenen Page?

Völlig Wurscht, denke ich. Wenn diese Funktion im Zusammenhang mit der Programmierung von Flash überhaupt sinnvoll verwendbar ist, dann ergibt allerhöchstens die Übergabe von poll1=0xff einen Sinn.

Ob S. schrieb:

Völlig Wurscht, denke ich. Wenn diese Funktion im Zusammenhang mit der Programmierung von Flash überhaupt sinnvoll verwendbar ist, dann ergibt allerhöchstens die Übergabe von poll1=0xff einen Sinn.

Auszug aus dem Datenblatt des ATmega8(L): Data Polling Flash "When a page is being programmed into the Flash, reading an address location within the page being programmed will give the value 0xFF. At the time the device is ready for a new page, the programmed value will read correctly. This is used to determine when the next page can be written. Note that the entire page is written simultaneously and any address within the page can be used for polling. Data polling of the Flash will not work for the value 0xFF, so when programming this value, the user will have to wait for at least tWD_FLASH before programming the next page. As a chip-erased device contains 0xFF in all locations, programming of addresses that are meant to contain 0xFF, can be skipped."

Also scheint diese Taktik so vorgesehen zu sein. Ich verstehe nur die Intention hinter diesem poll1-Wert des STK500v2-Protokolls nicht; denn wie du schon schriebst, könnte ja der AVRISP einfach eine beliebige Adresse innerhalb der aktuellen Page mit einem zu flashenden Wert ungleich 0xFF nehmen und diesen pollen, bis auch der zurückgelesene Wert dem zu schreibenden entspricht.

Aber irgendwas werden sich die Leute bei Atmel, die das Protokoll erfunden haben, ja dabei gedacht haben. Insofern warte ich nochmal ab, bis sich (hoffentlich) einer der avrdude-Entwickler hier meldet, die sich ja sicher damit auskennen werden.

Sherlock 🕵🏽‍♂️ schrieb:

Falls sich der Jörg Wunsch nicht meldet, schreibe ihn per PN an.

Hatte ich schon überlegt, dachte aber, es wäre besser, erstmal im Forum zu fragen.

Sherlock 🕵🏽‍♂️ schrieb:

Hast du schon in Erwägung gezogen, vom Arduino ISP Sketch abzugucken? https://github.com/arduino/arduino-examples/blob/main/examples/11.ArduinoISP/ArduinoISP/ArduinoISP.ino

Habe eben einen Blick reingeworfen und musste feststellen, dass dieses Programm wohl das STK500(v1)-Protokoll implementiert, also den Vorgänger, der von v2 sehr stark abweicht. Damit bringt mich dieser Code also leider nicht weiter.

Hier noch ein Update, für den Fall, dass einmal jemand mit der gleichen Frage diesen Thread finden sollte:

Ich habe es inzwischen herausgefunden, indem ich in meinen selbstgeschriebenen AVRISPv2-Programmer eine ATtiny12-Simulation inkl. Ausgabe der interessanten Parameter (via zweitem USART) eingebaut habe; der ATtiny12 hat bzw. hatte keinen RDY/BSY-ISP-Befehl und deshalb ist das Flash-Value-Polling nach dem Schreiben erforderlich.

Der Aufruf von avrdude an diesem Testprogramm mit der Anweisung zum Schreiben einer Hexdatei lieferte mir dann die Erkenntnis, dass avrdude tatsächlich die Anweisung zum Value Polling mit dem Parameter 'poll1' gleich 0xFF an den Programmer liefert, d.h. es ist damit wohl wirklich gemeint, welchen Wert jedes Flash-Byte nach einem Chip Erase hat. Somit muss der Programmer selbst ein Byte zum Testen heraussuchen (aus einer Page bzw. einem Word), das mit einem Wert ungleich poll1 geschrieben werden soll und dieses abfragen, was natürlich auch nicht weiter schwierig ist. Damit ist nun alles klar (bis auf den Parameter 'poll2', der wohl nicht für Flash Programming benutzt wird, also nur für den EEPROM – keine Ahnung, was es damit auf sich hat, aber das soll mich nun erst einmal nicht weiter interessieren).

Einige werden sich sicher fragen, warum ich mir nicht einfach den Quellcode von avrdude dafür angesehen habe – dazu sei gesagt, dass ich das zunächst versucht habe, leider sind aber meine C-Kenntnisse noch nicht ausreichend weit gediehen bzw. fehlt mir die Erfahrung im Lesen von professionellem C-Code; daher war das AVR-Testprogramm für mich z.Zt die einfachere Lösung.