Bootloader und Applikation gemeinsam Compilieren

Ich würde einen festen Einsprungvektor bauen, der immer auf die
gleiche Adresse geladen wird.  Von dort wird im Bootloader auf die
eigentliche Funktion gesprungen.  Globale Variablen sollten diese
Funktionen komplett meiden, dann bist du das Problem ebenfalls los.
(Der Bootloader selbst kann natürlich globale Variablen benutzen,
wenn er läuft, läuft ja die Applikation nicht.)

Die Adressen des Einsprungvektors kannst du über passend zurecht
gebogene Zeiger in einer Headerdatei deiner Applikation zur
Verfügung stellen, ungefähr so:

1

typedef int (*foo_t) (const char *);

2

static const foo_t foo = (foo_t)0x1234;

Die Applikation kann dann daher kommen und foo() wie eine ganz
normale Funktion behandeln:

1

int

2

runfoo(const char *s)

3

{

4

        return 42 + foo(s);

5

}

Weiß nicht, ich find's reichlich umständlich und fehleranfälliger
als die Sache mit dem Einsprungvektor.  Spätestens, wenn du nach
einiger Zeit die nächste Version des Bootloaders implementieren
musst und dann "im Feld" zwei verschiedene Versionen mit verschiedenen
Adressen für die Bibliotheksfunktionen hast, wirst du mächtig ins
Rudern kommen.

Man kann Bootloader und Applikation nicht zusammen manschen, das geht in 
die Hose.

Der Bootloader könnte einen SW-Interrupt benutzen und dort nen API-Call 
eintragen.
Und die Applikation ruft dann mit Funktionsnummer das API auf und kriegt 
nen Returnwert über den Erfolg.

Dazu müssen aber die API-Funktionen so geschrieben werden, daß sie 
keinen RAM belegen.
Alle temporären Variablen müssen auf dem Stack abgelegt werden.
Benötigt das API statische Variablen, müssen die von der Applikation mit 
einen API-Init Call angelegt werden. Z.B. es wird der Pointer auf malloc 
übergeben damit das API es aufrufen kann.


Peter

Thomas H schrieb:
> Hmm, naja das mit den verschiedenen Adressen, wenn sich der Bootloader
> ändert kann ich ja so oder so nicht beeinflussen

Du hast das immer noch nicht verstanden.

Du baust einen Einsprungvektor auf eine feste Adresse (bspw. ganz
an den Anfang oder kurz vor das Ende des Bootloaders).  Dessen
Adresse ändert sich nie wieder und die Reihenfolge seiner Einträge
auch nicht.  Die Applikation kennt damit ausschließlich diese
Adressen.

Dieser Vektor wiederum verzweigt auf die tatsächlichen Adressen im
Bootloader, mit einfachen Sprüngen.  Die werden dann vom Linker
aufgelöst (beim Linken des Bootloaders).  Wenn sich in einer nächsten
Version des Bootloaders diese Sprünge ändern, interessiert das die
Applikation kein bisschen.

klaus schrieb:
> Man kann sowas gut via Software Interrupt lösen. Der Bootloader
> installiert entsprechende Crypto-Funktionen über den Software Interrupt
> Handler, die Anwendung erzeugt dann einfach einen Software Interrupt zum
> Ausführen dieser Funktionen. Bin mir aber nur nicht sicher ob ARM Cortex
> M3 sowas bietet

Natürlich gibt es beim Cortex-M3 auch Software Interrupts, die bei ARM 
jetzt generell SuperVisor Call (SVC) genannt werden. Die alte 
Bezeichnung führte wahrscheinlich zu Verwechslungen mit Software 
Triggered Interrupts (STI), die einen ganz anderen Mechanismus 
verwenden.

Die Frage ist, was die Applikation machen soll. Soll sie eventuell 
eigene SVC bereitstellen? Dann wird das mit den SVC im boot loader 
schwierig (man könnte auf STI ausweichen, falls vorhanden). Ansonsten 
ist das mit SVC eine saubere Sache.

Ein anderer Ansatz wäre es, die API Funktionen mit dem boot loader in 
einen definierten Speicherbereich zu linken, und deren Adressen beim 
späteren Linken der Applikation zu laden (--just_symbols)

Gruß
Marcus