Hallo Zusammen, ich möchte folgendes realisieren, brauch aber eventuell einen kleinen Denkanstoss... Ein AVR1 besitzt einen Bootloader, der entscheiden kann, ob das über die UART eintrudelnde HEX-File für sich selbst ist, oder aber für einen AVR2 bestimmt ist. AVR2 besitzt ebenfalls einen Bootloader, der allerdings über die SPI mit AVR1 kommuniziert (Hardware-RESET von AVR2 leider nicht steuerbar). Wenn das ankommende HEX-File für AVR1 bestimmt ist, flash er sich mit dem HEX-File selbst, führt ein reset aus und die Applikation läuft. Wenn das über die UART ankommende HEX-File (an AVR1) allerdings für AVR2 bestimmt ist, soll AVR1 das HEX-File über die SPI an AVR2 "tunneln" und AVR2 soll sich mit dem HEX-File flashen. Dies setzt voraus, dass der Bootloader in AVR2 die Daten über die SPI-Schnittstelle entgegennimmt, nicht aber über die UART. Meine frage wäre nun, ob das so überhaupt funktionieren würde, was man beachten müsste und ob es bereits ähnliche Projekte gibt. Wie aufwändig wäre es vorhandene Bootloader (zb. AVRootload) mit der Funktion zu erweitern. Ist es sinnvoller, den AVR2 mit dem ISP-Protokoll zu flashen, also ohne Bootloader für AVR2. Quasi ein stinknormaler Bootloader für die serielle Schnittstelle mit einem zusatzfeature, das HEX-File über die SPI (später vielleicht I2C) weiterreichen zu können, oder aber das ISP-Protokoll zusätzlich zu unterstützen... Danke und Gruß Spice
Spice schrieb: > (Hardware-RESET von AVR2 leider nicht steuerbar). Damit scheidet ISP schon mal aus. Spice schrieb: > Wie aufwändig wäre es vorhandene Bootloader (zb. AVRootload) mit der > Funktion zu erweitern Nicht erweitern. Du musst die Kommunikation, die beim Bootloader über den UART läuft, ersetzen durch SPI. Du kannst aber auch den UART nehmen. Spart sogar noch eine Leitung. Dann musst du am AVR2 gar nichts ändern. Im AVR1 muß dann ein Softare-UART integriert werden, falls er nur 1 Hardware-UART hat. mfg.
Vielen Dank für die Infos, allergings habe ich vergessen zu erwähnen, dass das Design bereits fertig ist. Also es muss schon so laufen wie beschrieben, der Bootloader1 muss Daten über die UART entgegennehmen und über SPI an Bootloader2 durchreichen können... Bootloader2 muss quasi auf SPI umprogrammiert werden und Bootloader1 muss um eine Funktion erweitert werden, wo das Hexfile über die SPI-Schnittstelle "durchgeschliffen" wird. Ist sowas möglich? Reichen da die Bootsektoren aus um einen angepassten Bootloader zu flashen? Danke und Gruß Spice
Spice schrieb: > Ist sowas möglich? Sicher. >Reichen da die Bootsektoren aus um einen > angepassten Bootloader zu flashen? Um welche Controller geht es überhaupt? mfg.
AVR1 ist ein mega1284 und avr2 ist ein mega32
Spice schrieb: > AVR1 ist ein mega1284 und avr2 ist ein mega32 Ein normaler Bootloader sollte 1KB nicht überschreiten. Beim AVR1 kommt dann noch das "Weiterreichen" dazu. Das ist aber auch kein Riesenprogramm. Beim AVR2 wird die UART-kommunikation durch SPI ersetzt, sodaß sich da +-0 ergeben sollte. Das passt. Der 32 hat 4KB, vom 1284 habe ich gerade kein Datenblatt da, aber der 644 hat 8KB. Die hat der 1284 mindestens auch. mfg.
Thomas Eckmann schrieb: > Spice schrieb: >> AVR1 ist ein mega1284 und avr2 ist ein mega32 > > Ein normaler Bootloader sollte 1KB nicht überschreiten. Beim AVR1 kommt > dann noch das "Weiterreichen" dazu. Das ist aber auch kein > Riesenprogramm. > > Beim AVR2 wird die UART-kommunikation durch SPI ersetzt, sodaß sich da > +-0 ergeben sollte. > > Das passt. > Der 32 hat 4KB, vom 1284 habe ich gerade kein Datenblatt da, aber der > 644 hat 8KB. Die hat der 1284 mindestens auch. > > mfg. Das "Weiterreichen" könnte auch im Applikationsbereich implementiert werden... AVR1 muss also nicht unbedingt einen Bootloader-Abstieg machen, wenn AVR2 programmiert werden muss.
Tobias Frost schrieb: > Das "Weiterreichen" könnte auch im Applikationsbereich implementiert > werden... Welchen Sinn soll das haben? Die Kommunikation mit dem PC ist im Bootloader implementiert. Warum also nochmal in der Applikation? mfg.
...Weil AVR1 dann nicht in den Bootloader-Modus gehen muss um AVR2 zu programmieren... AVR1 könnte den Code abarbeiten und zusätzlich den AVR2 "flashen" bzw mit dem Hexfile versorgen... Die Idee ist nicht schlecht... Vielen Dank... Gruß Spice
@thomase: ich habe schneller geantwortet, als ich lesen bzw. gerade denken konnte... Du hast natürlich recht, der AVR1 muss eh im Bootloadermodus sein um das hexfile entgegen nehmen zu können :-) Danke auch für den Hinweis...
Gibts so ähnliche Projekte eigentlich? Die Bootloader sind ja meistens in ASM geschrieben, kann man da vielleicht auch mit C-Code zwischen funken, oder müsste man das alles in ASM implementieren? Danke und Gruß Spice
Selbstverständlich kann man mit C dazwischen funken. Ich habe mich nie mit dem AVR gcc intensiv beschäftigt aber Du mußt Dir die "calling convention" angucken (wie die Paramter übergeben werden, wo wird der Rückgabewert gespeichert wird) und evtl. welche Register Du verwenden und von welchen Du ein Backup (Stack) erstellen mußt. Wenn Du keine Literatur findest, einfach ein minimales C Programm schreiben und mit "-S" kompilieren, dann bekommst Du die Ausgabe in Assembler und kannst nachgucken wie es funktioniert.
Vielen Dank für die Infos, ich werde mich da mal schlaulesen/probieren... Wenn jemand mehr Informationen darüber hat, wäre ich über jeden "Schnipsel" oder Link dankbar... Schoenes WE, Gruß Spice
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.