Fragen zu Makefile-Konzept und Bootloader

Frank schrieb:
> Bei vielen Anwendungen auf gleicher Basis wird er immer mittgeschleppt.
Daher gibt es zB in git "module" , mit denen man externe repositories 
mit einer ganz bestimmten Version einbinden kann.

Frank schrieb:
> Funktioniert gut und ist übersichtlich,
Ja wird gerne so gemacht weil man die generierten Dateien von den 
manuell erstellten getrennt hat und leicht löschen etc. kann. Üblicher 
wäre allerdings ein Name wie "build" statt "obj".

Frank schrieb:
> weil der Zugriff auf Dateien außerhalb des
> bootloader-Unterverzeichnisses einen entsprechenden Pfad für die Objekte
> nach sich zieht,
Na und? Zum compilieren muss man ja auch auf Dateien ausserhalb des obj 
Verzeichnisses (Source) zugreifen? Oder wie war das gemeint?

Vielen Dank für die Antwort.

Dr. Sommer schrieb:
> Daher gibt es zB in git "module" , mit denen man externe repositories
> mit einer ganz bestimmten Version einbinden kann.

Ja, allerdings liest man über git-submodule so viele Schauergeschichten, 
dass ich davon erstmal Abstand nehmen wollte.
git-subtree scheint eine Alternative zu sein, aber ich wollte mir am 
Anfang nicht gleich alle Hürden dieser Welt antun.

> Ja wird gerne so gemacht weil man die generierten Dateien von den
> manuell erstellten getrennt hat und leicht löschen etc. kann. Üblicher
> wäre allerdings ein Name wie "build" statt "obj".

In "build" landen die Dateien, die dann weiterverwendet werden. .elf, 
.hex, .sym, .map, .a2l ...

> Na und? Zum compilieren muss man ja auch auf Dateien ausserhalb des obj
> Verzeichnisses (Source) zugreifen? Oder wie war das gemeint?

Die Regel im Makefile sagt: Nimm den Quellpfad, hänge ein "obj/" davor 
und das ist dann der Pfad zum Objekt. Bei einer Quelle "../foo/bar.c" 
ergibt das "obj/../foo/bar.c". "obj/.." hebt sich gegenseitig auf und 
bar.o landet nicht in "obj/foo/bar.o" sondern in "foo/bar.o". Das muss 
bei dieser Regel auch so sein, gefällt mir aber nicht, weil es die 
Objekte somit irgendwo verstreut. Wenn die Quelle noch weiter oberhalb 
des Projekts liegt, landet das Objekt "irgendwo" im Dateisystem. Also 
ist dieses Vorgehen für mich untauglich, falls ich weiter Quellen 
überhalb des Projekts verwenden will.

Auch Dir herzlichen Dank.

Peter Dannegger schrieb:
> Nein.
Klare Ansage :)

> Der Bootloader sollte möglichst alle Targets unterstützen, die man zu
> verwenden plant.
Puh, das klingt nicht so einfach aber sicher sinnvoll. Mit "Target" 
meinst Du verschiedene Controller einer Familie oder geht das bei Dir 
auch hersteller- oder gar architekturübergreifend? Bei mir hängt's 
aktuell ziemlich an Flash-Sektoren etc. Die Adressen definiert das 
Linker-File. Im Fall meines Cortex-M hole ich mir Stackpointer und 
Reset-Handler aus der Vektortabelle der Anwendung. Wie sieht das bei Dir 
aus?

> Der Bootloader wird auch immer einzeln geflasht und dann erst über ihn
> die Applikation. Nur damit stellt man sicher, daß er überhaupt
> funktioniert und ein weitere Update möglich ist. D.h. daß keine HW- oder
> SW-Fehler vorliegen.
Schlagendes Argument. Find ich gut.

> P.S.:
> Ups, Du meinst wohl nen Bootloader für Speichermedien bei jedem Reset.
> Dann vergiß mein Gesülze. Das bezieht sich auf Bootloader für einen MC.
Nein und nein. Ich vergess es nicht :) Konkret ist es im Moment der 
STM32F4 und es soll ein XCP (on CAN, später evtl. Ethernet)-Bootloader 
werden. Oberste Prämisse ist wie so oft die Unzerstörbarkeit durch 
Anwenderfehler und Flashabbrüche.

Unterstützt oder brauchst Du ein Bootloader-Update durch den Bootloader?

Frank schrieb:
> Unterstützt oder brauchst Du ein Bootloader-Update durch den Bootloader?

Zumindest im automotiv Bereich ist ein Bootloader Update Standard.