Hallo Forum, ich habe da eine Frage. Ich möchte mir das AT90USBKEY Demo-Kit zulegen. Jetzt habe ich gelesen dass es da ein „bootloader“ und die dazugehörige Software „flip“ gibt. Jetzt ist meine Frage wofür man denn so einen bootloader benötigt? Kann man mit einem bootloader das gleiche machen wie z.b. wenn ich ein Programm über meine JTAG- Schnittstelle laden? Oder für was benötigt man einen bootlaoder? Danke für eure Antworten!! Grüße Dirk
ein Bootloader lädt ein "Betriebssystem" oder ein Programm von externen Datenträgern z. B. über RS-232 Otto
Grundsaetzlich ist ein Bootloader dazu da ein jungfraeuliches Teil aus dem Sumpf zu ziehen. D.h. am Anfang hat der micro noch kein Anwenderprogramm, der BL stellt eine Kommunikation her, die es ermoeglicht ein Anwenderprogramm zu laden. Implementierungen von Bootloadern sind recht verschieden zwischen verschiedenen Herstellern. Gruss, Robert
Ein Bootloader ist ein von der Hauptapplikation unabhängiges Programm, welches die eigentliche Applikation über eine definierte Hard- und Software-Schnittstelle in Empfang nimmt und den Controller entsprechend programmiert. Je nach Architektur des Controllers muss die Hauptapplikation nichts weiter davon beachten. Es kann aber auch sein, dass beide aufeinander abgestimmt sein müssen, z.B. was Startadressen, Interrupt-Vektoren etc. betrifft. Im einfachsten Fall nimmt der Bootloader direkt die auf dem PC generierten Daten (z.B. HEX-File) entgegen, wandelt sie passend und schreibt sie in den Speicher. Erweiterte Versionen können z.B. Verschlüsselung unterstützen oder bestimmte Teilaufgaben (EEPROM löschen oder partiell neu beschreiben) erledigen. PC-Programme wie FLIP erleichtern die Kommunikation mit dem Bootloader, da sie die entsprechenden Befehle gleich passend mit Daten versehen, eine Light-Version kann aber auch einfach über ein Terminal-Programm mit dem User kommunizieren - der User muss dann halt alles von Hand machen. Bootloader können so geschrieben sein, dass auch die Applikation selbst den Bootloader starten kann (dann muss sie aber vom Bootloader "wissen") oder Teile des Bootloaders (Schreibe Byte, lösche Speicher, etc.) können auch von der Applikation verwendet werden -> In Application Programming. Das spart Speicherplatz. Je nach Architektur werden wiederum spezielle Anforderungen an den Bootloader gestellt. So kann es sein, dass z.B. Befehle für das Schreiben des Speichers in einem bestimmten Speicherbereich stehen müssen, damit sie ausgeführt werden können. Ein Vorteil von Bootloadern ist, dass man sie ohne oder nur geringem zusätzlichen Hardware-Aufwand (z.B. Taster bei Reset) starten kann und keine Hardware für Programmieren braucht. Im Gegensatz zu einem Programmier-Tool bietet ein Bootloader nicht die Möglichkeit, Breakpoints zu setzen oder Register auszulesen. Ralf PS: Wow, eigentlich wollte ich nur drei Sätze drüber verlieren... staun
Der Hauptvorteil eines Bootloaders : Der Kunde kann eine neue Firmware laden.
>Grundsaetzlich ist ein Bootloader dazu da ein jungfraeuliches Teil aus >dem Sumpf zu ziehen. Falls der BL schon drauf ist hats schon mal gepoppt :-) Ganz jungfräulich ist es nicht mehr! Falls der "BL" fest im uC ist würd ich den "Bootstrap Loader " nennen.
Hallo zusammen, vielen Dank für eure Erklärung. Danke auch an Ralf an deine, doch sehr ausführliche Beschreibung. Ich kann mir jetzt ziemlich gut vorstellen was ein Bootloader ist. Bin mal gespannt wie ich den dann beim AT90USBKEY verwenden muss. Ich denke mit der Zeit werde ich dann tiefere Einblicke in so einen Bootloader bekommen :o) Danke nochmal an alle und viele Grüße, Dirk
Ich könnte Dir übrigens einen AT90USBKEY verkaufen. Meine, ich hätte noch einen daliegen. Falls noch nicht zu spät, schau ich heute abend gerne mal nach. Grüße, t
Hmmm... Die Frage des OP hab ich mir auch schon oft gestellt. MIt ist zwar klar, was ein Bootloader ist, aber wofür er zB auf einem kleinen µC wie AVR sinnvoll ist erschliesst sich mir nicht wirklich: Diese µC haben eine ISP (In-System Programmier-Schnittstelle), können also programmiert werden, ohne sie aus der Zielschaltung zu entfernen. Bei geschicktem Layout kann man die ISP-Pins auch für die Anwendung nutzen. Man verliert also keine Pins für die ISP-Technik. Für einen Bootloader muss man jedoch immer Kommunikationsleitungen vorsehen, auch wenn die Applikation im Endeffekt garkeine Kommunikation braucht. Zudem belegt ein Bootloader wertvollen Speicher. Wenn ein Bootloader immer eine ganze Anwendung lädt, kann man doch ebensogut den ISP verwenden... Einzig in dem Fall, wo man Verschlüsselung braucht oder Module nachgeladen werden, versteh ich den Sinn eines Bootloaders. Ein Beispiel wäre eine Spiele-Anwendung, die eine Grafik-API zur Verfügung stellt und einzelne Spiel-Module nachladen kann, welche diese Grafik-API benutzen. Wenn der Anwender ein anderes Spiel spielen will, würde das entsprechende Modul nachgeladen werden. Das würde aber einen dynamischen Lader erfotrdern, weil man die Resourcen wie RAM und Sprungadressen beim Laden verwalten/fixen muss, der Code muss PIC (position independent) erzeugt sein und andere Eigenschaften erfülen, die man beim Erzeugen beachten muss. Die meisten Bootloader, die hier unterwegs sind, können das aber gerade nicht und nur eine Applikation komplett rauswerfen und ne neue reinladen. Das sieht man schon daran, daß diese Bootloader idR HEX- oder BIN-Dateien brauchen, und zB mit ELF nix anfangen können. Vielleicht bringt ja jemand Licht ins Dunkel :-) Johann --
Johann L. wrote: > Die meisten > Bootloader, die hier unterwegs sind, können das aber gerade nicht und > nur eine Applikation komplett rauswerfen und ne neue reinladen. Das liegt daran, daß sowas vom Compiler nicht unterstützt wird. Vom Prinzip her könnte ein Bootloader Code nachladen, bloß hat wohl bisher keiner einen Sinn darin gesehen. SPI kann das generell nicht. > Das > sieht man schon daran, daß diese Bootloader idR HEX- oder BIN-Dateien > brauchen, und zB mit ELF nix anfangen können. Was ist an ELF denn so besonders? HEX-Files könnte man genau so gut nachladen (wenn man wollte). > Vielleicht bringt ja jemand Licht ins Dunkel :-) Ich entwickele gern mit Bootloader, das ist so schön praktisch. Ich brauche dann nämlich nicht spezielle Programmierhardware mitschleppen, den AVR direkt an die COM rangepappt, fertsch. Nur zu Anfang muß ich einmal das STK500 bemühen, um den Bootloader zu flashen und die Fuses zu setzen. Ich muß beim Bootloader auch nur einen Pin nach außen führen (SPI: 4 Pins), der dann praktischer Weise gleich zu Debugzwecken dienen kann. Auch kann ich den Resetpin benutzen und trotzdem programmieren, z.B.: ATtiny85 = 6 IOs, ATtiny84 = 12 IOs, ATtiny861 = 16 IOs usw. Peter
Hab mal einen Link auf die gute Erklärung von Ralf im Wiki hinzugefügt. http://www.mikrocontroller.net/articles/Bootloader Vlz. könnte man da sogar ganz übernehmen
Angenommen, du möchtest einen Mikrocontroller programmieren, der weder frei zugänglich, weil embedded, oder mehrere (Kilo-)Meter entfernt vom Rechner platziert ist. Wie würdest du das machen? Richtig, du musst ein anderes Transfermedium als das klassiche ISP via Parallel-/USB-port wählen. Hier kommt dann der Bootloader als Übersetzer ins Spiel.
> Hab mal einen Link auf die gute Erklärung von Ralf im Wiki hinzugefügt.
Danke, es freut mich, dass meine Erklärung so gut war :) Gut fürs
Selbstwurstsein grins
Ralf
Peter Dannegger wrote: > Ich entwickele gern mit Bootloader, das ist so schön praktisch. Ditto hier. Hast du den PC-Part ins AVR-Studio eingebunden? Ich scheitere daran, dass ich es nicht schaffe, im Tools Menü einen vernünftigen Menüpunkt zu erzeugen. Klar kann ich den Menüpunkt erzeugen und der Loader wird auch aufgerufen. An der ganzen Sache stört mich nur, dass ich es nicht schaffe, in das abzusetzende Kommando den Projektnamen generisch einzusetzen. Mein Kommando sieht so aus c:\pboot\pboot -B9600 -Pdefault/timer.hex (oder so ähnlich, habs jetzt nicht im Kopf) Es sollte aber so aussehen c:\pboot\pboot -B9600 -Pdefault/%PROJEKT%.hex oder so ähnlich. Nur konnte ich nicht rausfinden, ob es an dieser Stelle sowas wie Variablen gibt. Und jedesmal bei einem Projektwechsel diese Commandline anpassen ist fehleranfällig und mühsam. Wie machst du das?
Karl heinz Buchegger wrote: > Hast du den PC-Part ins AVR-Studio eingebunden? Nein, ich benutze für den WINAVR und Bootloader eine Batch-Datei. > Klar kann ich den Menüpunkt erzeugen und der Loader wird auch > aufgerufen. An der ganzen Sache stört mich nur, dass ich es nicht > schaffe, in das abzusetzende Kommando den Projektnamen generisch > einzusetzen. Man könnte im Make einen festen Namen für das Hexfile eintragen oder auch gleich aus dem Make das PC-Programm aufrufen. Im allgemeinen erlauben IDEs aber die Übergabe von Parametern an ein Fremdprogramm. Ich hab aber noch nicht intensiv mit dem AVRStudio gearbeitet. Ich benutze es nur als Programmmer mit dem STK500. Jeder jungfräuliche AVR muß ja einmal aufs STK500, um den Bootlader verpaßt zu bekommen. Peter
>Im allgemeinen erlauben IDEs aber die Übergabe von Parametern an ein >Fremdprogramm. Im speziellen leider nicht. Mit AVRSTudio geht das schlicht und einfach nicht. Oliver
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.