Hallo! In einem geplanten Aufbau soll es einen Hauptcontroller geben (wahrscheinlich Infineon C167) und einen ATTiny84 für eine kleine andere Aufgabe. Diese werden dann über SPI miteinander kommunizieren. Letzten Endes möchte ich den ATTiny ohne zusätzlichen Programmer über den Hauptcontroller updaten können. Ich habe schon ein Bisschen gesucht, bin aber leider nicht ganz fündig geworden. Ich habe die ATMEL Appnote über In-System Programming ( http://www.atmel.com/Images/doc0943.pdf ) und gefunden, wo schon mal ein paar Informationen drinstehen. Meine Frage: Ist sowas möglich? Wenn ja, hat jemand ein paar Links zu weiterem Lesematerial? Ist es vielleicht sinnig, sich die Sources von AVRDude oder PonyProg anzuschauen, oder wird das zu kompliziert, wenn es auch einfacher geht? Kommt es zu Problemen, da die SPI Verbindung auch zur Kommunikation genutzt werden soll? Vielen Dank im Voraus für Anregungen und Infos!
AVR Mikrocontroller lassen sich über die SPI Schnittstelle programmieren, während der Reset-Pin aktiv ist. Das Protokoll ist irgendwo dokumentiert. Alternativ könntest Du einen Bootloader einsetzen - der ATtiny programmiert sich dann "selbst" mit Daten, die er von dem anderen Controller empfängt.
Hi und danke für die Antwort. Genau, solch eine Doku wäre auf jeden Fall sehr nützlich. Das müsste doch eigentlich auch ein recht verbreiteter Anwendungsfall sein. Wundere mich ein wenig, dass ich kaum Informationen oder ähnliche Projekte finde. Ich scheine noch mit den falschen Stichwörtern zu suchen.
Benny schrieb: > Hi und danke für die Antwort. > Genau, solch eine Doku wäre auf jeden Fall sehr nützlich. Das müsste > doch eigentlich auch ein recht verbreiteter Anwendungsfall sein. Eigentlich nicht. Im Grunde interessiert das nur die Leute, die die ISP Brenner herstellen und die aus einem darüberliegenden Protokoll die entsprechenden 'Kommandos' an den ISP Kern im AVR schicken. So viele gibts davon aber nicht. Ich würde das auch pragmatisch sehen: Bootloader und gut ists. Bootloader hat auch noch den Vorteil, dass du dir garantiert die Fuses nicht zerschiessen kannst.
Ja, das stimmt. Allerdings muss man dann jeden ATTiny mit dem Bootloader bestücken, was dann für eine größere Produktion schlecht bis unmöglich wäre. Ich hatte früher mal ATMega16 Controller gesehen, die man bereits mit installiertem Bootloader kaufen konnte. Gibt es sowas auch für den ATTiny84? Wird also doch kompliziert :)
Hier bin ich noch über einen Board internen Link gestolpert: Beitrag "Atmel SPI Programmieren (Protokoll?)"
Naja gut, da stehen einige Dinge im Datenblatt. Aber die Appnote ist schon recht alt und der Controller, den ich verwenden möchte, ist da nicht aufgeführt. Deswegen wäre es schon interessant zu wissen, ob jemand sich schon mit der Materie befasst hat und eventuelle Stolperfallen aufzeigen kann. Gerade beim Flashen ist schnell mal irgendwas verfused, oder was auch immer.
Hi >Ja, das stimmt. Allerdings muss man dann jeden ATTiny mit dem Bootloader >bestücken, was dann für eine größere Produktion schlecht bis unmöglich >wäre. Nö. Ditri suchen, der programmierte ATTiny liefert. MfG Spess
Benny schrieb: > Genau, solch eine Doku wäre auf jeden Fall sehr nützlich. Das müsste > doch eigentlich auch ein recht verbreiteter Anwendungsfall sein. Drum gibt's dazu auch ein ganzes Kapitel im Datenblatt (serial programming oder so)... Siehe auch Beitrag "ATtiny45 Bootloader"
Alles klar, vielen Dank schon mal für den nützlichen Input. Also wird wohl der Bootloader die unkomplizierteste Variante sein. I'll look into that :)
Hi! OP DELIVERS! Ich möchte der Vollständigkeit halber nochmal eine kurze Zusammenfassung geben für Leute, die vor dem gleichen Problem stehen wie ich. In der Tat finden sich alle nötigen Informationen im Datenblatt. Beim ATTiny84 auf Seite 163, Kapitel 19.5: Serial Programming. Der (bei mir) 8KB große Flash Speicher ist linear angelegt. Die Adressierung erfolgt in WORD Schritten, die nächst größere "Einheit" ist eine Page. Adresse 0 ist das erste Wort, Adresse 1 das zweite. Auf eine Page passen (beim ATTiny44 und ATTiny84) 32 Words. Der Speciher wird folgendermaßen beschrieben: Die Reset Leitung wird auf GND gezogen und das Kommando "Programming Enable" per SPI geschickt. Kommandos haben immer 4 Byte, die übertragen werden müssen, hier sind es die Bytes
1 | 0xAC
|
2 | 0x53
|
3 | 0x00
|
4 | 0x00
|
Wenn es geklappt hat, wird mit dem 3. gesendeten Byte das 2. Byte 0x53 zurückgesendet. Dies hat bei mir erst lange nicht funktioniert. Man muss GENAU darauf achten, wie die Clock eingestellt ist: Die gesendeten Daten werden auf Rising Edge übernommen. Ich habe es mit einem Oszi und Trial and Error eingestellt. Irgendwann war auf dem Rückkanal dann die Antwort 0x53 zu sehen. Tabelle 19-12 des Datenblattes beschreibt alle möglichen Commands. Wichtig hier ist, dass man für die Commands immer im Programming Mode sein muss! Auch für's Auslesen, beispielsweise! Nun sendet man erstmal einen Chip Erase.
1 | 0xAC
|
2 | 0x80
|
3 | 0x00
|
4 | 0x00
|
Dieser löscht das ganze Flash, selektiv Adressen löschen ist, soweit ich weiß, nicht möglich. Als nächstes kann man eine Adresse beschreiben. Zum Testen kann irgendein WORD genommen werden ( 0xAA55 ). Der Controller hat eine ganze Page als Buffer. Diesen Buffer lädt man voll und schreibt ihn dann mit einem Schreibbefehl auf den Controller. Wie oben beschrieben , ist das Flash Word adressiert. Trotzdem gibt es zwei Befehle zum Buffer laden, nämlich High Byte und Low Byte einer Adresse. Es muss erst das Low Byte geladen werden! Ablauf: Lade Low Byte -> Lade High Byte (bis zu 32 mal, dann Page Buffer voll) -> Schreibe Page. Die Befehle dazu sind in der Tabelle zu finden. Als abschließendes Beispiel hier noch ein Bisschen Pseudo Code zum Schreiben von 0xAA55 an Adresse 0:
1 | // Lade low byte an Puffer Adresse 0
|
2 | spisend( 0x40 ) //OP Code |
3 | response = spiread(); |
4 | spisend( 0x00 ) //Adresse MSB |
5 | response = spiread(); |
6 | spisend( 0x00 ) //Adresse LSB |
7 | response = spiread(); |
8 | spisend( 0x55 ) //Daten |
9 | response = spiread(); |
10 | |
11 | // Lade high byte an Puffer Adresse 0
|
12 | spisend( 0x48 ) //OP Code |
13 | response = spiread(); |
14 | spisend( 0x00 ) //Adresse MSB |
15 | response = spiread(); |
16 | spisend( 0x00 ) //Adresse LSB |
17 | response = spiread(); |
18 | spisend( 0xAA ) //Daten |
19 | response = spiread(); |
20 | |
21 | |
22 | // Schreibe Page, beginnend bei Adresse 0
|
23 | spisend( 0x4C ) //OP Code |
24 | response = spiread(); |
25 | spisend( 0x00 ) //Adresse MSB |
26 | response = spiread(); |
27 | spisend( 0x00 ) //Adresse LSB |
28 | response = spiread(); |
29 | spisend( 0x00 ) |
30 | response = spiread(); |
Nach dem Schreiben muss man die Reset Leitung wieder auf High setzen, um die Programmiermodus zu verlassen. Auch wichtig: Wenn man die zweite Page schreiben möchte, ist die Adresse nicht 0x02, sondern 0x20, da man die Anfangsadresse, nicht die Page Nummer angeben muss! Das ist ein grober Überblick. Timing muss man kaum beachten, es gibt ein Busy Flag, das man pollen kann, wenn man eine Page schreibt. Auch sehr einfach, wenn man die Command Sets erst mal geblickt hat. Hoffe, dass ich jemandem helfen konnte. Grüße!
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.