Application und Bootloader als getrennte Projekte?

[desaster (Gast)]

Hi,

zuerst einmal, ich bin im Bereich der µC Programmierung noch nicht ganz 
solange dabei, also steinigt mich bitte nicht für "dummen Fragen".

Jetzt zu meinem Anliegen. Ich bin gerade dabei ein Konzept für einen 
Bootloader zu erstellen. Hierzu habe ich das Forum und die Application 
Notes (von Atmel) zum Thema Bootloader durchgearbeitet und dachte, dass 
man Bootloader und Application als getrennte "Dinge" betrachtet und 
dementsprechend auch in getrennten Projekten entwickelt.

Jetzt hatte ich heute eine hitzige Diskussion mit einem älteren 
Kollegen, der meinte, dass das Quatsch ist. Besser ist, die beiden Teile 
in einem Projekt zu vereinigen und über das Linker-Skript in separate 
Speicherbereiche zu mappen. Dies bedeutet aber auch, das nur "einmal" 
compiliert wird und als Output eine Datei (Bootloader + Application) 
entsteht. Als wesentlichen Vorteil nannte er, und das kann ich auch
nachvollziehen, dass alle Teile (also Bootloader und Application aus 
einem Projekt heraus) debugbar sind.

Nun bin ich mir leider etwas unsicher, ob das konzeptionell so OK ist, 
da man ja beim FW-Update immer die eine Datei (Bootloader + Application) 
einspielt. Softwareseitig muss man dann entsprechend das unerlaubte 
Update des Bootloaders verhindern. Des weiteren unterscheidet sich dies 
natürlich auch von den Application Notes, die ich mir angeschaut habe.

Deshalb jetzt meine Fragen:

Wie habt ihr das implementiert (strikte Projekttrennung zwischen 
Bootloader und Application)?
Was spricht gegen und für eine Vereinigung von Bootloader und 
Application zu einem Projekt?

Danke desaster

[PittyJ (Gast)]

Bei uns wurde das getrennt gehalten. Das hatte den Vorteil, man konnte 
den gleichen Bootloader für verschiedene Projekte nehmen.
Änderungen am Bootloader mußten dann auch nicht in allen Projekten 
nachgepflegt werden.

[Karl H. (kbuchegg)]

> Wie habt ihr das implementiert (strikte Projekttrennung zwischen
> Bootloader und Application)?

Strikt getrennt

> Was spricht gegen und für eine Vereinigung von Bootloader
> und Application zu einem Projekt?

Dagegen: Das geht IMHO komplett am Sinn eines Bootloaders vorbei. Ein 
ISP Brennprogramm nimmt man ja auch nicht mit ins Projekt auf. Sowohl 
ein Brennprogramm als auch ein Bootloader sind meiner Sichtweise nach 
Teil der Toolchain, genauso wie ein Brennprogramm auch Teil der 
Toolchain ist. Nur das diesmal dann eben ein Teil der Toolchain im AVR 
selber residiert. Und debuggen muss ich den auch nicht mehr, wenn er 
erst einmal läuft. Der ist ein eigenständiges Projekt und wird für sich, 
losgelöst von allem anderen in den AVR gebrannt. Ich seh den als Teil 
des 'Setups' eines neuen Prozessors, genauso wie die Einstellung der 
Fuses Teil dieses Setups ist. Ist dieses 'Setup' abgeschlossen 
(Bootloader brennen + Fuses setzen), erst dann ist der µC bereit für 
seinen eigentlichen Applikationseinsatz (wobei man sinnigerweise die App 
gleich über den Bootloader in den µC brennt. Dann hat man auch die 
Gewissheit, dass dieser Schritt funktioniert)

Dafür: Aus meiner Sicht eigentlich nichts. Ausser dass man dann den 
Bootloader auf die App abstimmen kann, bzw. eventuell in der App Teile 
des Bootloaders weiterverwenden kann. Aber auf dieses 'eventuell' würde 
ich ehrlich gesagt nicht bauen. Ein Bootloader macht nur dann Sinn, wenn 
ich damit den µC auch dann neu flashen kann, wenn alles andere schief 
gegangen ist. D.h. ein Bootloader, den ich nur über die App aktivieren 
kann - da kann ich es auch gleich bleiben lassen.

[desaster (Gast)]

Ich sehe das genauso. Für mich sind das auch völlig getrennte Dinge. Ich 
werde mal die Pros und Cons sammeln und micht dann in eine neue 
Diskussion stürzen.

[Hagen R. (hagen)]

Ich bin ebenfalls der Meinung das das strikt getrennte Projekte sind.

Und wir hinterfragen mal den Satz "es ist für das Debugging besser 
beides als ein Projekt zu betrachten". Mit einem solchen Debugging 
findet man Fehler in der gegebenen Kombination aus Quelltexten. Mit 
anderen Worten ein solches Debugging trifft über Fehler nur die Aussage 
das sie in exakt dieser Kombination aus Bootloader und Applikation 
aufgetreten sind. Ein solches Debugging kann keine Aussage darüber 
treffen wie sich der Bootloader Code mit einer komplett anderen 
Applikation verhält. Da das Ziel eines Bootloaders es aber ist mit 
vielen unterschiedlichen Anwendungen, sogar Anwendungen die der 
Bootloaderprogrammierer sich nicht vorstellen kann, korrekt zu laufen, 
ist ein solches Debugging ziemlich wertlos ja kontraproduktiv.

Das Debugging ist also kein Indiz noch Beweis für die Aussage deines 
Kollegen, eher ein Indiz dafür den Bootloader strikt selbstständig zu 
entwickeln.

Gruß hagen

[Andreas (Gast)]

> Softwareseitig muss man dann entsprechend das unerlaubte
> Update des Bootloaders verhindern.

Das ist schonmal Mist. So ein Bootloader sollte im Idealfall absolut 
minimalistisch und "failsafe" sein, außerdem liegt er in einem 
schreibgeschützten Speicherbereich.
Alleine schon standardmäßig Hex-Files mit eingebautem Desaster-Potential 
zu erzeugen ist nicht sehr clever... Wie machst du das dann beim Verify? 
"Bitte nur bis 0xFF00 prüfen, danach kommt der alte Bootloader der mit 
dem neuen File nicht passt aber so bleiben muss wie er ist"???

In einem "großen" Projekt alles zu Debuggen ist auch sinnlos, weil die 
beiden Programme überhaupt nichts miteinander zu tun haben.

Bibliotheken o.ä. in einen festen Speicherbereich zu legen damit 
App&Loader sie verwenden führt auch zum Chaos.
Wenn sowas geplant ist dann lass das Update von der App in einen 
externen Flash/EEPROM kopieren und baue nur einen Kopier-Bootloader.
So kannst du den Bootloader unverändert lassen egal ob das Update über 
LAN/USB/RS232 kommt, das macht dann alles die App.

Wenn dein Kollege Probleme mit der Debugger-Einrichtung hat sollte er 
mal seine Toolchain aufräumen und nicht gleich die ganze Architektur 
versauen.

[Peter D. (peda)]

Es sind natürlich 2 völlig separate Projekte, alles andere macht keinen 
Sinn.

Ist quasi wie beim PC das BIOS und das OS.
Das BIOS weiß nichts vom OS und dem Linux/Windows ist wiederum das BIOS 
egal.