Hallo Leute, ich habe ein VB-Programm geschrieben, mit dem ich meine WLAN/Bluetooth Eigenbaugeräte updaten kann. Die Geräte besitzen einen Bootloader. Ich habe allerdings einige Geräte mit Tiny13 bzw Tiny2313. Diese sind schon voll vom Programm, sprich kein Platz für Bootloader. Ich würde jetzt gerne mit, entweder einem Eigenbauprogrammer, oder besser noch mit dem fertigen USBasp-Programmer diese Geräte über mein Terminal updaten können. Dazu habe ich einige Fragen: 1. Weiß jmd. wie man den USBasp anspricht ohne Atmel-Studio oder diese "MyAVR Progtool Software". 2. Wie programmiert man die Atmels/Tinys eigentlich per ISP? Welches Protokoll, bzw. wie muss man da vor gehen? Der Programmer sollte dann in C sein, ich denke mal, vll. wäre es sogar besser selbst einen Programmer zu programmieren, wie muss ich die .hex Datei zu dem Chip senden über SPI?
Marius D. schrieb: > 1. Weiß jmd. wie man den USBasp anspricht ohne Atmel-Studio oder diese > "MyAVR Progtool Software". Es gibt einige etablierte Protokolle, z.B. "stk500v2" Marius D. schrieb: > 2. Wie programmiert man die Atmels/Tinys eigentlich per ISP? Welches > Protokoll, bzw. wie muss man da vor gehen? Das steht alles im Datenblatt (memory programming / serial programming) wenn Du es komplett "zu Fuß" machen willst. Schneller geht es wahrscheinlich mit avrdude oder ähnlicher schon fertiger Software für diesen Zweck.
ich glaub für das myAVR Progtool gibt es auch kommandozeilen-Befehle und auch eine API... mal bei myAVR anfragen ;-) ... dann ist da natürlich noch das allseits beliebte avr-dude :-P Gruß
Marius D. schrieb: > 1. Weiß jmd. wie man den USBasp anspricht ohne Atmel-Studio oder diese > "MyAVR Progtool Software". Der USBASP ist ein HID Gerät. Er spricht sein eigenes proprietäres Protokoll. Richtige Dokumentation scheint es dafür nicht zu geben, aber die Firmware ist ja Open Source. Sonderlich kompliziert wird es nicht sein, sondern nur die ISP-Pakete über USB tunneln. > 2. Wie programmiert man die Atmels/Tinys eigentlich per ISP? Welches > Protokoll, bzw. wie muss man da vor gehen? Das steht im Datenblatt. Der USBASP hat selber fast keine Intelligenz. Statt dessen muß die Software am anderen Ende der USB-Verbindung (vulgo: auf dem PC) die richtigen Aufrufe der ISP Funktionen vornehmen. > Der Programmer sollte dann in > C sein, ich denke mal, vll. wäre es sogar besser selbst einen Programmer > zu programmieren Kannst du natürlich machen. Andere Leute nehmen einfach fertige Software dafür. Das kanonische Tool ist avrdude, aber speziell für Windows gibt es gefühlt 1000 weitere Tools.
Axel S. schrieb: > Marius D. schrieb: >> 1. Weiß jmd. wie man den USBasp anspricht ohne Atmel-Studio oder diese >> "MyAVR Progtool Software". > > Der USBASP ist ein HID Gerät. Er spricht sein eigenes proprietäres > Protokoll. Richtige Dokumentation scheint es dafür nicht zu geben, aber > die Firmware ist ja Open Source. Sonderlich kompliziert wird es nicht > sein, sondern nur die ISP-Pakete über USB tunneln. > >> 2. Wie programmiert man die Atmels/Tinys eigentlich per ISP? Welches >> Protokoll, bzw. wie muss man da vor gehen? > > Das steht im Datenblatt. Der USBASP hat selber fast keine Intelligenz. > Statt dessen muß die Software am anderen Ende der USB-Verbindung (vulgo: > auf dem PC) die richtigen Aufrufe der ISP Funktionen vornehmen. > >> Der Programmer sollte dann in >> C sein, ich denke mal, vll. wäre es sogar besser selbst einen Programmer >> zu programmieren > > Kannst du natürlich machen. Andere Leute nehmen einfach fertige Software > dafür. Das kanonische Tool ist avrdude, aber speziell für Windows gibt > es gefühlt 1000 weitere Tools. Ja es gibt alles, ich habe auch genug Programmer per USB da (bspw. MyAVR, Diamex All AVR, etc..), darum geht es nicht, es geht viel mehr darum, ein Modul zu haben, was ich meinen Freunden geben kann, die auch meine Geräte nutzen (Modellbahn), und dann selber mit meinem Terminal ein FW-Update durchführen können, ohne Benutzerunfreundliche Software. Das Datenblatt Tiny13 habe ich mir bereits angeguckt, da steht das soweit drin wie das geht, allerdings verstehe ich das absolut nicht, wie ich da die Daten senden muss. Da sind binäre Pakete (bis zu 4) angegeben, und dann mit div. Sachen wie H oder oooooo etc.. Ich würde mal gerne wissen, was ich senden muss, wenn ich bspw. die ersten sagen wir mal 4 Zeilen der Firmware programmieren will
1 | :1000000009C021C020C01FC01EC01DC01CC01BC015 |
2 | :100010001AC019C011241FBECFE9CDBF10E0A0E661 |
3 | :10002000B0E0E2ECF2E002C005900D92A036B1071C |
4 | :10003000D9F720E0A0E6B0E001C01D92A336B207D8 |
Marius D. schrieb: > Ja es gibt alles, ich habe auch genug Programmer per USB da (bspw. > MyAVR, Diamex All AVR, etc..), darum geht es nicht Warum fragst du dann spezifisch nach dem USBASP Protokoll, wenn es doch gar nicht darum geht? > es geht viel mehr > darum, ein Modul zu haben, was ich meinen Freunden geben kann, die auch > meine Geräte nutzen (Modellbahn), und dann selber mit meinem Terminal > ein FW-Update durchführen können, ohne Benutzerunfreundliche Software. Ja. Und? Machen. Ob das jetzt einfacher wird als eine Batch-Datei, die avrdude aufruft, weiß ich nicht. Kommt darauf an, was du (bzw. deine Kumpels) als "einfach" empfinden. > Das Datenblatt Tiny13 habe ich mir bereits angeguckt, da steht das > soweit drin wie das geht, allerdings verstehe ich das absolut nicht Dabei können wir dir nicht helfen. Datenblatt lesen mußt du schon selber. Zumindest dann, wenn du den Anspruch hast, alles selber machen zu wollen. Allerdings ist das einigermaßen trivial. Man muß Reset auf L halten und kann dann mit dem SPI ganz normal Daten an den µC senden (und zeitgleich empfangen). Und im Datenblatt stehen alle Kommandosequenzen die der µC versteht und was sie bewirken. Was ist daran jetzt schwer?
Marius D. schrieb: > Ich würde mal gerne wissen, was ich senden muss, wenn ich bspw. die > ersten sagen wir mal 4 Zeilen der Firmware programmieren will > :1000000009C021C020C01FC01EC01DC01CC01BC015 Dazu must du erst mal Hex-File decodieren, da steht alles nötige drin um deine AVRs zu programmieren. Marius D. schrieb: > MyAVR, Diamex All AVR, etc..), darum geht es nicht, es geht viel mehr > darum, ein Modul zu haben, was ich meinen Freunden geben kann, die auch > meine Geräte nutzen (Modellbahn), und dann selber mit meinem Terminal > ein FW-Update durchführen können, ohne Benutzerunfreundliche Software. Man kann natürlich in einen M328 die nötigen 2KB oder 4KB für einen Tiny packen, die beiden miteinander verbinden und beim einschalten oder Reset werden diese dann automatisch von M328 geflasht. Immer vorausgesetzt, ein ISP-Stecker ist vorhanden. Das wäre die einfachste Lösung, aber nach deinen Fragen zu urteilen, übersteigt das deine Kenntnisse bei weitem. Axel S. schrieb: > zu wollen. Allerdings ist das einigermaßen trivial. Man muß Reset auf L > halten und kann dann mit dem SPI ganz normal Daten an den µC senden (und > zeitgleich empfangen). Und im Datenblatt stehen alle Kommandosequenzen > die der µC versteht und was sie bewirken. Was ist daran jetzt schwer? Die selbe Frage wollte ich auch stellen.
Marc V. schrieb: > Marius D. schrieb: >> Ich würde mal gerne wissen, was ich senden muss, wenn ich bspw. die >> ersten sagen wir mal 4 Zeilen der Firmware programmieren will >> :1000000009C021C020C01FC01EC01DC01CC01BC015 > > Dazu must du erst mal Hex-File decodieren, da steht alles nötige drin > um deine AVRs zu programmieren. > > Marius D. schrieb: >> MyAVR, Diamex All AVR, etc..), darum geht es nicht, es geht viel mehr >> darum, ein Modul zu haben, was ich meinen Freunden geben kann, die auch >> meine Geräte nutzen (Modellbahn), und dann selber mit meinem Terminal >> ein FW-Update durchführen können, ohne Benutzerunfreundliche Software. > > Man kann natürlich in einen M328 die nötigen 2KB oder 4KB für einen > Tiny packen, die beiden miteinander verbinden und beim einschalten > oder Reset werden diese dann automatisch von M328 geflasht. Immer > vorausgesetzt, ein ISP-Stecker ist vorhanden. > Das wäre die einfachste Lösung, aber nach deinen Fragen zu urteilen, > übersteigt das deine Kenntnisse bei weitem. > > Axel S. schrieb: >> zu wollen. Allerdings ist das einigermaßen trivial. Man muß Reset auf L >> halten und kann dann mit dem SPI ganz normal Daten an den µC senden (und >> zeitgleich empfangen). Und im Datenblatt stehen alle Kommandosequenzen >> die der µC versteht und was sie bewirken. Was ist daran jetzt schwer? > > Die selbe Frage wollte ich auch stellen. Ja, das habe und mache ich ja auch alles, Fuses lesen/schreiben, Chip erase etc.. geht auch, das problem ist flash schreiben. Beim flash schreiben, klappt das nicht, wie ist denn dort die Reihenfolge? Ich sammel 32 byte, schreibe diese sequentiell (LSB, MSB, LSB, MSB, etc..) und dann schreibe ich die Page. Klappt aber nicht.
Marius D. schrieb: > Ich sammel 32 byte, schreibe diese sequentiell (LSB, MSB, LSB, MSB, > etc..) und dann schreibe ich die Page. Klappt aber nicht. Wenn ich mit ISP arbeite, benutze ich mein Eigenbau Prommer, funzt ohne Probleme schon seit mehr als 14 Jahren. Habe noch 2 käufliche als Reserve, aber dieser ist mir am liebsten. Alles notwendige über uC wird vom PC aus *.xml ausgelesen, deshalb. Die Prozedur ist folgende: Adress (zum SetAdress) wird Hi-Lo geschickt, danach folgen Pagesize Bytes genau wie im Hex-File, danach PageWrite. Diese Bytes werden aber natürlich zuerst ins PageBuffer geschrieben. Allerdings lese ich beim PC zuerst den ganzen Hex-File in ein Array, welches vorher auf 0xFF gesetzt wurde. PC prüft, ob es eine ganze Page mit 0xFF gibt, wenn ja wird die einfach übersprungen, wenn nicht, wird die Page programmiert. Prommer bestätigt sowohl die empfangenen als auch die ausgeführten Befehle. Es gab mal bei ATMEL eine AppNote, ich habe diese am Anfang benutzt, danach um einige Befehle erweitert, so dass mein Prommer jetzt nur noch mit sich selbst kompatibel ist. Prommer selbst ist in Assembler, ich kann heute abend versuchen, ob ich den noch irgendwo auf DVDs finde, um dir den genauen Vorgang beim Flashen zu schicken.
:
Bearbeitet durch User
Marc V. schrieb: > Marius D. schrieb: >> Ich sammel 32 byte, schreibe diese sequentiell (LSB, MSB, LSB, MSB, >> etc..) und dann schreibe ich die Page. Klappt aber nicht. > > Wenn ich mit ISP arbeite, benutze ich mein Eigenbau Prommer, funzt > ohne Probleme schon seit mehr als 14 Jahren. Habe noch 2 käufliche > als Reserve, aber dieser ist mir am liebsten. > Alles notwendige über uC wird vom PC aus *.xml ausgelesen, deshalb. > Die Prozedur ist folgende: > > Adress (zum SetAdress) wird Hi-Lo geschickt, danach folgen Pagesize > Bytes genau wie im Hex-File, danach PageWrite. Diese Bytes werden > aber natürlich zuerst ins PageBuffer geschrieben. > Allerdings lese ich beim PC zuerst den ganzen Hex-File in ein Array, > welches vorher auf 0xFF gesetzt wurde. > PC prüft, ob es eine ganze Page mit 0xFF gibt, wenn ja wird die > einfach übersprungen, wenn nicht, wird die Page programmiert. > > Prommer bestätigt sowohl die empfangenen als auch die ausgeführten > Befehle. > > Es gab mal bei ATMEL eine AppNote, ich habe diese am Anfang benutzt, > danach um einige Befehle erweitert, so dass mein Prommer jetzt nur > noch mit sich selbst kompatibel ist. > Prommer selbst ist in Assembler, ich kann heute abend versuchen, > ob ich den noch irgendwo auf DVDs finde, um dir den genauen Vorgang > beim Flashen zu schicken. Hi, bei mir geht ja alles soweit. allerdings habe ich anscheinend beim Attiny13 512 bytes/page, anstelle von 32 wie es im datenblatt steht. 2 Byte/Word passt, aber wenn ich buffer fülle, dann page write mache (mit page = 0), fängt er oben beim flash an, mache ich allerdings page = 1 ist er genau ab der hälfte. Alles was > 1 ist ist genauso aufgebaut (ungerade wie ne 1, gerade wie eine 0)?!
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.