Forum: Mikrocontroller und Digitale Elektronik Bootloader - Verständnisfrage Speicheraufteilung


von Bootloadwissbegieriger (Gast)


Lesenswert?

Anlässlich des vor kurzem gestellten Problems mit Flashen
innerhalb des Bootloaders kam bei mir folgende Frage auf:

Meines Wissens nach braucht "der AVR" seine Vektor-Tabelle
am Anfang des Flash-Bereichs. Wenn nun aber ein Bootloader
im oberen (im Bootloader-Speicherbereich) arbeitet und
Interrupts nutzen will würde er ja beim Flashen eines
Nutzer-Programms seine Vektor-Tabelle die ab Null steht
überschreiben. Wo ist mein Missverständnis? Ist die Vektor-
Tabelle eines Bootloaders implizit automatisch an seinem
Speicheranfang den man ihm durch die Fuses definiert? Oder
kann ein Bootprogramm keine Interrupts nutzen wenn es ein
Benutzerprogramm flasht?

Ich bitte um Klarstellung hier sodass ich nicht stundenlang
ein Datenblatt wälzen muss.

von Einer K. (Gast)


Lesenswert?

Bootloadwissbegieriger schrieb:
> Oder kann ein Bootprogramm keine Interrupts nutzen ....?
so ist es wohl.

von Thomas E. (thomase)


Lesenswert?

Bootloadwissbegieriger schrieb:
> Oder
> kann ein Bootprogramm keine Interrupts nutzen wenn es ein
> Benutzerprogramm flasht

Doch natürlich kann er das. Es gibt hier einen Artikel, in dem das alles 
erklärt wird.

https://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung

von Bootloadwissbegieriger (Gast)


Lesenswert?

Thomas E. schrieb:
> Es gibt hier einen Artikel,

Danke sehr.
Also demnach meine erste Vermutung:

Bootloadwissbegieriger schrieb:
> Ist die Vektor-
> Tabelle eines Bootloaders implizit automatisch an seinem
> Speicheranfang den man ihm durch die Fuses definiert?

(wenn man jede Woche einen Bootloader schreibt dann braucht
man sowas natürlich nicht fragen ...)

von Einer K. (Gast)


Lesenswert?

Arduino F. schrieb:
> so ist es wohl.
Ist falsch...

Dann habe ich ja auch mal wieder was gelernt...
Danke.

von Bootloadwissbegieriger (Gast)


Lesenswert?

.... hmmmm ..... und woher weiss der AVR nach dem Ausführen
des Bootloaders (Sprung zum Benutzerprogramm) dass jetzt die
Vektor-Tabelle ab Adresse Null gilt? Die Fuses die die
Bootloader-Startadresse und damit die Vektor-Tabelle bestimmen
haben sich ja durch den Sprung zum Benutzerprogramm nicht
geändert.

von Stefan R. (1994rstefan)


Lesenswert?

In dem man IVSEL im MCUCR auf 0 setzt.
Grundsätzlich muss man nach starten des Bootloaders IVSEL im MCUCR auf 1 
setzen um dem Mikrocontroller mitzuteilen, dass die Interruptvektor 
Tabelle nicht bei 0x01 sondern am Anfang des Bootloaders beginnt. Wenn 
der Bootloader fertig ist setzt man IVSEL wieder auf 0 und der 
Mikrocontroller nutz wieder die Interruptvektoren ab 0x01.

In kurz: Die Angabe wo die Tabelle für Interrupts beginnt wird nicht 
über die Fuses gesetzt.

: Bearbeitet durch User
von Bootloadwissbegieriger (Gast)


Lesenswert?

Danke an Stefan für die erschöpfende Auskunft!

von Axel S. (a-za-z0-9)


Lesenswert?

Bootloadwissbegieriger schrieb:
> .... hmmmm ..... und woher weiss der AVR nach dem Ausführen
> des Bootloaders (Sprung zum Benutzerprogramm) dass jetzt die
> Vektor-Tabelle ab Adresse Null gilt?

Er weiß es nicht.

Nach einem Reset ist IVSEL=0 (Vektoren am Beginn des Flashs) und 
Interrupts sind global disabled. So lange die Interrupts disabled 
bleiben, ist die Position der Vektortabelle auch egal.

Wenn der Bootloader Interrupts verwenden will, dann wird er i.d.R. die 
Vektortabelle auf den Bootloaderbereich umbiegen wollen, indem er 
IVSEL=1 setzt. Weil der Rest des Flashs ja u.U. leer ist bzw. sich der 
Bootloader nicht darauf verlassen kann, was da drin steht. In diesem 
Fall muß der Bootloader vor dem Sprung in das Anwendungsprogramm 
natürlich die Vektortabelle wieder zurück stellen (IVSEL=0).

Wenn der Bootloader keine Interrupts nutzt, muß er IVSEL nicht anfassen, 
sondern könnte sich darauf verlassen, daß es vom Reset her auf 0 steht. 
Sauberer (im Sinne von "funktioniert immer") ist es natürlich, wenn der 
Bootloader immer IVSEL=0 setzt, bevor er in die Anwendung springt.

von Peter D. (peda)


Lesenswert?

Aber nicht alle AVR können das, z.B. ATmega48 oder ATtiny nicht.

von Axel S. (a-za-z0-9)


Lesenswert?

Peter D. schrieb:

> Aber nicht alle AVR können das, z.B. ATmega48 oder ATtiny nicht.

Wenn ein AVR gar keinen separaten Boot Loader Block im Flash hat, dann 
stellt sich die Frage idR nicht. Wenn er lediglich die Interrupt- 
Vektoren nicht verschieben kann, dann kann der Bootloader halt keine 
Interrupts nutzen. Ist doch alles einfach und logisch nachvollziehbar.

[Den Rest versehentlich gelöscht - Frank M. (ukw), sorry]

: Wiederhergestellt durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sorry, Axel, ich habe gerade in meiner neuen Funktion als Moderator 
versehentlich auf "Text bearbeiten" statt auf "Antwort mit Zitat" 
geklickt und damit Dein Posting überschrieben. Es war mir danach nur 
noch möglich, Deinen von mir verstümmelten Beitrag zum größten Teil, 
aber nicht im Ganzen wiederherzustellen. Tut mir leid, da muss ich noch 
etwas üben. :-(

Axel S. schrieb:
> Wenn ein AVR gar keinen separaten Boot Loader Block im Flash hat, dann
> stellt sich die Frage idR nicht. Wenn er lediglich die Interrupt-
> Vektoren nicht verschieben kann, dann kann der Bootloader halt keine
> Interrupts nutzen. Ist doch alles einfach und logisch nachvollziehbar.

Geht trotzdem:

   Konzept für einen ATtiny-Bootloader in C

Insbesondere:

   https://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C#Sharen_von_Interrupts

Ist aber schon etwas härterer Stoff. ;-)

: Bearbeitet durch Moderator
von Axel S. (a-za-z0-9)


Lesenswert?

Frank M. schrieb:
> Sorry, Axel, ich habe gerade in meiner neuen Funktion als Moderator

Herzlichen Glückwunsch zur "Beförderung" ;)

> Axel S. schrieb:
>> Wenn ein AVR gar keinen separaten Boot Loader Block im Flash hat, dann
>> stellt sich die Frage idR nicht. Wenn er lediglich die Interrupt-
>> Vektoren nicht verschieben kann, dann kann der Bootloader halt keine
>> Interrupts nutzen. Ist doch alles einfach und logisch nachvollziehbar.
>
> Geht trotzdem:
>
>    Konzept für einen ATtiny-Bootloader in C
>
> Ist aber schon etwas härterer Stoff. ;-)

Das stand im wesentlichen in dem Teil meines Posts, der der Schere zum 
Opfer gefallen ist: ohne Bootloaderunterstützung kann man die 
Funktionalität zwar auch hinpfriemeln, aber schön wird das nicht.
Und: angesichts des ohnehin eher mageren Flashs in den Tinies ist es 
auch nur sehr selten sinnvoll.

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
Noch kein Account? Hier anmelden.