Hallo, ich bin gerade dabei, einen AVR-ISP-Programmer zu implementieren, der via STK500v2-Protokoll mit avrdude kommuniziert. An für sich funktioniert mein (Asm-)Programm soweit, nur habe ich beim Befehl CMD_PROGRAM_FLASH_ISP bisher im Falle eines angeforderten 'value polling' dieses durch eine feste Wartezeit von 5 ms ersetzt, weil mir dessen genaue Funktion im Zusammenspiel mit STK500v2 nicht klar ist. Die AppNote AVR068 sagt dazu nur: "When value polling is used to determine when a programming operation is complete, poll1 must be supplied. This value indicates which value will be read from the device until the programmed value is read." 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? Weitere Angaben dazu gibt's in der AppNote nicht. Ich wäre sehr dankbar, wenn jemand Klarheit schaffen könnte. Grüße P.S.: Ja, ich hatte diesen Thread bereits gestern Abend gepostet und kurz darauf wieder gelöscht, weil ich dachte, ich hätte eine Lösung gefunden, war dann aber doch nicht der Fall.
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.
:
Bearbeitet durch User
Johannes F. schrieb: > Insofern warte ich nochmal ab, > bis sich (hoffentlich) einer der avrdude-Entwickler hier meldet, die > sich ja sicher damit auskennen werden. Falls sich der Jörg Wunsch nicht meldet, schreibe ihn per PN an. 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 Ich meine, dass dieser zumindest ein Subset vom stk500 Protokoll verwendet.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Bitte 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.