www.mikrocontroller.net

Forum: Compiler & IDEs Interruptvektortabelle


Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich arbeite auf einem ATMEGA32 mit Bootloader. Die Interrupts sollen im
Bootloader verarbeitet werden (das funktioniert soweit).
Vom Bootloader getrennt soll es nun eine Applikation geben. Da aber die
Interruptvektoren im Bootloader stehen, müssen diese auf die
"Applikations-Tabelle" umgebogen werden, damit Interrupts auch in der
Applikation abgearbeitet werden können.
Also ergeben sich 2 Fragen:

1. Wie kann man die Interrupttabelle des Bootloaders ändern? Der RESET,
UART_RECV und TIMER0_OVFL Interrupt sollen aber unverädert bleiben.
Wenn ich versuche an der Stelle, wo die entsprechenden
Interruptvektoren liegen (bei mir 0x7000-0x7054, 4k Bootsektor) eine
Section anzulegen, meckert der Linker (Ist ja auch klar, da eine
Adressüberschneidung vorliegt)
Kann man nicht dem Linker die ISR-Func Adressen irgendwie manuell
mitgeben?

2. Da vom Bootloader aus dann die Adresse 0x0000 angesprungen werden
soll, darf das Startup in der Applikation nicht mehr ausgeführt werden!
(Würde beim Rücksprung in den Bootloader alles schmeißen, da der SP,
usw. falsch wären)
Wie kann man verhindern, dass ein Startup-Code miteingebunden wird?

Vielen Dank schon mal!
MfG Tobi

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Hab vermutet, dass das mit der "gcrt1.S" (Startupcode) zusammnhängt,
kann die Datei weder auf meinem Rechner (WIN-AVR 4.0 + GCC) noch im
Netz fiden!!!

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hab vermutet, dass das mit der "gcrt1.S" (Startupcode)
> zusammnhängt, kann die Datei weder auf meinem Rechner (WIN-AVR
> 4.0 + GCC) noch im Netz fiden!

(Deine Ausrufezeichentaste klemmt.  Eigentlich musst du das auch gar
nicht ausrufen, wen willst du denn hier anschreien? ;-)

So?  Wo hast du denn da gesucht?  Wenn du einfach nur den Sourcecode
mit installiert hättest, hättest du diese Datei auf jeden Fall
dabei gehabt.

Was soll eigentlich "WIN-AVR 4.0 + GCC" sein?  WinAVR enthält den
GCC, compiliert für den AVR (auch bekannt als AVR-GCC), aber was
dabei die Versionsnummer 4.0 soll, weiß ich nicht.  WinAVR benennt
seine Versionen nach Datum.  Vom GCC gibt es zwar eine Version 4.0,
aber die gilt besonders für das Target AVR noch als recht
,grün', sodass sie wohl selbst in der nächsten WinAVR-Version
noch nicht dabei sein wird.

> 1. Wie kann man die Interrupttabelle des Bootloaders ändern? Der
RESET,
> UART_RECV und TIMER0_OVFL Interrupt sollen aber unverädert bleiben.
> Wenn ich versuche an der Stelle, wo die entsprechenden
> Interruptvektoren liegen (bei mir 0x7000-0x7054, 4k Bootsektor) eine
> Section anzulegen, meckert der Linker (Ist ja auch klar, da eine
> Adressüberschneidung vorliegt)

Wenn du sowas exotisches machen willst, dann solltest du dich zuvor
wohl mit der Art und Weise, wie die Interruptvektoren in der avr-libc
verwaltet werden, tiefgreifend auseinandersetzen.

Vorab: ich denke, dass es die einfachste und sinnvollste Lösung
wäre, im Bootloader einfach auf die Interrupts zu verzichten und
dann die Vektortabelle in der Applikation zu belassen.  Aber das ist
deine Sache, wenn du den komplizierteren Weg gehen willst, musst du
dir wohl oder übel die Mühe machen, den Krempel auch
tiefgreifend erstmal zu verstehen.

Bis zu gcrt1.S bist du ja zumindest schon vorgedrungen.  Dass du aber
nicht in der Lage warst, diese Datei sinnvoll zu finden, lässt mich
ein wenig zweifeln, ob du die restlichen nötigen Details auch
wirklich beherrschen werden könnst.  Anyway, gcrt1.S definiert
einfach in einer Schleife alle Interruptvektoren so, dass die auf
__bad_interrupt zeigen.  Alle diese Eintrittspunkte sind als `weak'
deklariert, damit wird entsprechenden gleichnamigen Eintrittspunkten,
die von der Applikation geliefert werden, dann vom Linker der Vorrang
eingeräumt.  (Ohne `weak' würde sich der Linker über die
Doppeldefinition beklagen.)  Die Vektoren sind übrigens nur einfach
__vector_1 bis __vector_N durchnummeriert (das hättest du schon aus
dem Aufbau des SIGNAL-Makros erfahren können).

Du musst also letztlich in deinem Bootloader alle (dich
interessierenden) Eintrittspunkte __vector_1 bis __vector_N belegen.

> Kann man nicht dem Linker die ISR-Func Adressen irgendwie manuell
> mitgeben?

Im Prinzip sollte sogar das gehen, indem du auf der Linker-
Kommandozeile entsprechende Symboldefinitionen übergibst.  Ist
natürlich je nach Prozessor einiges an Schreibarbeit, aber wenn du
das unbedingt willst...  Beispiele solltest du in der avr-libc-Doku
(indirekt) finden, dort beispielsweise in der Erläuterung, wie man
die Speicherallozierung von malloc() auf andere Bereiche (bspw. den
externen SRAM) umbiegen kann.

> 2. Da vom Bootloader aus dann die Adresse 0x0000 angesprungen werden
> soll, darf das Startup in der Applikation nicht mehr ausgeführt
> werden!  (Würde beim Rücksprung in den Bootloader alles
> schmeißen, da der SP, usw. falsch wären)

Das leuchtet mir nun überhaupt nicht ein.  Warum willst du denn
zwischen Applikation und Bootloader hin- und herspringen?  So ist das
eigentlich nicht gedacht.  Normalerweise fangen beide so an, als
hätten sie den kompletten Prozessor und wären die alleinigen
Programme auf dem Chip.  Wenn der Bootloader mit dem Laden fertig ist,
springt er einfach die Applikation an, und diese beginnt dann wie nach
einem Reset.  (Sie sollte sich lediglich dessen bewusst sein, dass die
IO-Register nicht ,jungfräulich' sind.)  Falls die Applikation den
Bootloader anspringen will, beginnt der dann ebenfalls wieder ganz von
vorn, d.h. die Applikation hat an dieser Stelle einfach die Steuerung
aufgegegen.

Es tut übrigens dabei nichts zur Sache, ob man ein wenig `shared
code' nehmen will, also z.B. Funktionen des Bootloaders aus der
Applikation aufrufen will.  In diesem Falle hat halt die Applikation
über den Stack die Oberhoheit, aber das ist ja überhaupt nicht
tragisch.  Lediglich bei Benutzung globaler Variablen muss man die
Ressourcenverteilung manuell organisieren, falls der shared code auf
solche zugreifen können soll.  Das sollte sich aber durch
Verschieben der .data-Section in einem von beiden Teilen machen
lassen.

> Wie kann man verhindern, dass ein Startup-Code miteingebunden wird?

Das wird wirklich nur gehen, indem du deinen eigenen Startup-Code
schreibst.  Ehrlich gesagt: die am wenigsten wünschenswerte
Variante.  Ich würde sowas versuchen zu vermeiden, da es eine
maintenance nightmare werden kann.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"2. Da vom Bootloader aus dann die Adresse 0x0000 angesprungen werden
soll, darf das Startup in der Applikation nicht mehr ausgeführt
werden!
(Würde beim Rücksprung in den Bootloader alles schmeißen, da der SP,
usw. falsch wären)"


Soweit ich weiß, wird der Stack immer noch zweimal gesetzt, das 2. mal
im Main.
Das Main kann also weder rekursiv aufgerufen werden, noch irgendwohin
zurückkehren.

Da das kaum einen stört, wurde es bisher wohl nicht als Bug eingestuft.
Es sind quasi 8 Bytes überflüssiger Code.


Peter

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
btw, soweit ich weiß verbietet der C-Standard das Aufrufen der Funktion
main() vom Benutzer-Code.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An welcher Stelle verbietet er das?  Mir ist keine bekannt.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> An welcher Stelle verbietet er das?  Mir ist keine bekannt.

Mist, schon wieder C++ mit C verwechselt (im Anhang C.1.2 im
C++-Standard stehts); in C++ darf man nichtmal die Adresse von main
nehmen.

Anhang C listet die Inkompatibilitäten von C++ zu C auf. Das heißt du
hast Recht, in C durfte man main() wohl rekursiv aufrufen.

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

@ Jörg:
Vielen Dank für die ausführliche Antwort. Nein, anschreien will ich
keinen :-)
Meinte eigentlich das AVR-Studio 4.0 (zum debuggen) mit dem AVR-GCC.(Da
hab ich einen Wurm reingebracht.)

> Bis zu gcrt1.S bist du ja zumindest schon vorgedrungen.  Dass du
> aber nicht in der Lage warst, diese Datei sinnvoll zu finden, lässt >
mich ein wenig zweifeln, ob du die restlichen nötigen Details auch
> wirklich beherrschen werden könnst.

Ja, ich zweifle auch dran, dass ich das hinbekomme. Ehrlich gesagt, bin
ich recht neu IM AVR-Gewerbe. Ich kenn mich mit dem C505 recht gut aus
und hab da mit der KEIL µ-Vision 2 Entwicklungsumgebung gearbeitet. Da
hab ich sowas wie oben beschrieben bereits am Laufen :-) Da gibt's ja
die "Startup.asm", die man leicht einbinden kann und damit lassen
sich die Interruptvektoren umgebiegen und die restlichen
Initialisierungen selbst einfügen. Nur sowas hab ich im GCC direkt noch
nicht gefunden
Das die Vektoren von 1 .. N im SIGNAL.H definiert sind, hab ich schon
gewusst :-)

Meine Idee war einen voll ohne Applikation laufenden Bootloader
hinzubekommen. Dieser soll dann überprüfen, ob es eine gültige
Applikation (durch Berechnung einer CRC16 Checksumme über den
Application-Flash Bereich, die im EEPROM abgespeichert ist) gibt und
diese dann "anspringen". Falls es keine Applikation gibt, läuft der
Bootloader alleine. Das setzt vorraus, dass ich die Interrupts im
Bootloader halten muß. Der Bootloader soll im Falle einer ungültigen
Applikation über die UART dann die (nun gültige) Applikation empfangen
und brennen.
Man kann dann sich ganz leicht ein PC Programm (Denke mal, wenn ich
hier erwähne, dass ich unter Windows programmiere gibt's Ärger :-))
)zaubern, das per UART mit dem Bootloader des ATMEGA quatscht. So kann
ich Applikationen auf Controllerebene basteln und diese dann beqeuem
und schnell in den ATMEGA brennen.
Daher müssen die Interrupts (eigentlich ja nur der UART-Interrupt) im
Bootloader stehen.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich kenn mich mit dem C505 recht gut aus und hab da mit der KEIL
> µ-Vision 2 Entwicklungsumgebung gearbeitet. Da hab ich sowas wie
> oben beschrieben bereits am Laufen :-) Da gibt's ja die
> "Startup.asm", die man leicht einbinden kann und damit lassen sich
> die Interruptvektoren umgebiegen und die restlichen
> Initialisierungen selbst einfügen.

Prinzipiell kannst du das mit GCC/avr-libc auch machen, aber ich halte
diese Vorgehensweise für grundlegend riskant.

Zwischen C run-time startup (crt) und Compiler besteht eine Art
,Vertrag', die internen Details sind dabei Verhandlungssache zwischen
diesen beiden und keine öffentliche Schnittstelle.  Dadurch werden
solche Dinge garantiert wie das Herstellen des normgerechten Zustands
bis zum Start von main().  Falls in Absprache zwischen Compiler und
Bibliothek daran mal aus irgendwelchen Gründen Änderungen vorgenommen
werden sollten, möchten die beiden das tun können, ohne noch mit
weiteren Partnern verhandeln zu müssen.  In einem solchen Falle
riskierst du nach einem Upgrade der Entwicklungsumgebung einfach, dass
du diesen Vertrag brichst (da du dein eigenes, dann nicht mehr
vertragsgemäßes startup benutzt).


> Nur sowas hab ich im GCC direkt noch
> nicht gefunden

Braucht man eigentlich auch nicht.  avr-libc hat sich die größte Mühe
gegeben, alle Arten von customization als Optionen vorzusehen (durch
Modifikation von globalen Linkersymbolen von der Kommandozeile aus
oder durch Benutzung der .initN-Sections).  Der einzige Mangel, der
mir am derzeitigen gcrt1.S bekannt ist ist, dass man die
Interruptvektoren nicht ausblenden kann (wäre für bootloader zum
Platzsparen interessant).  Das sollte sich aber auch noch einbauen
lassen.

> Das die Vektoren von 1 .. N im SIGNAL.H definiert sind, hab ich
schon
> gewusst :-)

signal.h (Kleinschreibung) ;-)  C ist case sensitive.

> Meine Idee war einen voll ohne Applikation laufenden Bootloader
> hinzubekommen. Dieser soll dann überprüfen, ob es eine gültige
> Applikation (durch Berechnung einer CRC16 Checksumme über den
> Application-Flash Bereich, die im EEPROM abgespeichert ist) gibt und
> diese dann "anspringen". Falls es keine Applikation gibt, läuft
der
> Bootloader alleine.

Das ist vernünftig.

> Das setzt vorraus, dass ich die Interrupts im
> Bootloader halten muß.

Überhaupt nicht.  Für das bisschen bootloader brauchst du keine
Interrupts.  Den reset-Vektor kannst du unabhängig von den restlichen
Vektoren verbiegen, und das sollte genügen.

Die UART-Routinen bekommst du auch ohne Interrupts schnell genug hin.
Fülle einfach für jede ROM-Page einen internen Puffer und definiere in
deinem Protokoll, dass nach jeder Page auf eine Bestätigung durch den
Bootloader gewartet werden muss.  Das erspart dir selbst irgendwelche
Notwendigkeit für ein handshake.

Beispiele für AVR910-style bootloader gibt's wie Sand am Meer.  Es
gibt auch ein oder zwei Beispiele für STK500-style loader, das ist
besonders dann interessant, wenn man über einen USB-seriell-Wandler
arbeiten will, da das STK500-Protokoll besser den Anforderungen des
paketorientierten Datentransfers via USB gerecht wird als das dumme
request-response-Protokoll von AVR910.  Das beste mir bekannte
Beispiel findest du bei Matthias Weißers USBisp, ein Bootloader, der
in die 2 KB boot section eines ATmega8 passt und ein abgerüstetes
STK500-Protokoll spricht.

Die Software vom USBisp steht unter GPL.  Wäre die Frage (die du
Matthias sicher auch einfach selbst stellen kannst), selbst wenn man
das Teil in einem kommerziellen Projekt benutzen will, sollte die GPL
meiner Meinung nach dann erfüllt sein, wenn man seine Änderungen am
Bootloader veröffentlicht, ohne dass die eigentliche Applikation davon
berührt ist.  Das wird in den meisten Fällen tolerabel sein,
alternativ kannst du ja versuchen, ob du für den bootloader mit
Matthias eine BSD-style license aushandeln kannst.
(,Veröffentlichen'
bedeutet in diesem Falle die Weitergabe deiner eigenen Änderungen im
Sourcecode an diejenigen, denen du dein Gerät gibst, wobei diese es
dann auch beliebig anders weitergeben oder veröffentlichen dürfen.  Du
musst den Sourcecode auch nur auf Anforderung hin weitergeben, musst
aber den Empfänger auf sein Recht hinweisen.)

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"und damit lassen sich die Interruptvektoren umgebiegen"

Es scheint mir, als ob Du das Datenblatt nicht gelesen hast.
Alle ATMega außer dem ATMega48 haben das IVSEL-Bit, womit bequem die
Interrupts in den Bootloader und zurück geschaltet werden können.

Den Startup-Code zu verbiegen, ist also nicht nötig.


Peter

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal Hi!

@ Peter:
Doch, das weiß ich. Würde bei meinem Konzept aber nicht viel helfen ...


@ Jörg
Aber jetzt muß ich mal mein Konzept überdenken, Danke!

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Nur der Vollständigkeit halber:

mit

_attribute_((naked)) SIGNAL(...)
{
  asm volatile("jump 0x0002");
}

können die Interruptvektoren "verbogen" werden. Das kostet nicht viel
Speicher und ist schön in der C-Datei unterzubringen.
So konnte ich mein Problem wie oben beschrieben lösen...

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.