ATTiny84 über anderen µC programmieren?

Gast #2749094
Lesenswert?

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!
Gast #2749110
Lesenswert?

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.
Gast #2749131
Lesenswert?

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.
#2749149
Lesenswert?

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.
Gast #2749162
Lesenswert?

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 :)
Gast #2749384
Lesenswert?

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.
Gast #2749439
Lesenswert?

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
Gast #2776923
Lesenswert?

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!

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren