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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bootloadwissbegieriger (Gast)


Bewertung
0 lesenswert
nicht 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 Arduino Fanboy D. (ufuf)


Bewertung
-2 lesenswert
nicht lesenswert
Bootloadwissbegieriger schrieb:
> Oder kann ein Bootprogramm keine Interrupts nutzen ....?
so ist es wohl.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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 Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:
> so ist es wohl.
Ist falsch...

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

von Bootloadwissbegieriger (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
Danke an Stefan für die erschöpfende Auskunft!

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


Bewertung
0 lesenswert
nicht 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)


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

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


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.