Hi gibt es Argumente die dagegen sprechen warum ein Bootloader, neben der Bootlader Funktionalität auch die Applikation beinhalten sollte? Also der Bootloader ist gleichzeitig ein Motorsteuergerät und ein Bootloader. jenachdem ob man später beschliesst eine neue Firmware drauf zu tun, kann man später eine 2te memory bank benutzen um eine reine Applikationsfirmware hinterher zu laden. Danke
Interessante Frage! Wann ist ein Bootloader eine Applikation, und wann nicht? Und wie kommt man überhaupt auf solche (absurden) Ideen?
Wenn Bootloader+Applikation eine Einheit wären, würde er sich dann beim Update selbst überschreiben müssen? Was passiert, wenn das Update mitten drin fehlschlägt? Hast du genug Speicher, um alles zweimal im Flash zu haben (alt und neu)? Wenn nicht, würde man sinnvollerweise Bootloader und Applikation voneinander trennen.
klaus schrieb: > Hi > > gibt es Argumente die dagegen sprechen warum ein Bootloader, neben der > Bootlader Funktionalität auch die Applikation beinhalten sollte? > Also der Bootloader ist gleichzeitig ein Motorsteuergerät und ein > Bootloader. jenachdem ob man später beschliesst eine neue Firmware drauf > zu tun, kann man später eine 2te memory bank benutzen um eine reine > Applikationsfirmware hinterher zu laden. Warum nicht 1x Bootloader und 2 Slots für die Applikation (1 Slot mit Factory Default bzw. Fallback Firmware)? Ein Argument gegen dein Vorhaben ist versehentliches Lockout. Wenn du also eine Firmware aufspielst, die ein Bug in der Bootloader Funktion hat.
klaus schrieb: > gibt es Argumente die dagegen sprechen warum ein Bootloader, neben der > Bootlader Funktionalität auch die Applikation beinhalten sollte? Nachteile: 1. Neue Anwendung und alte müssen gemeinsam gleichzeitig in den Flashspeicher passen. 2. Nach Empfang der neuen Anwendung und Ablage im Flashspeicher muss man die alte Anwendung durch die neue ersetzen. Dazu braucht es einen weiteren kleinen Flashspeicherbereich für die dazu nötigen Instruktionen. 3. Ein Fehler in der Anwendung (z.B. Watchdog-Fehlprogrammierung, fehlerhafte Fortentwicklung der Empfangsroutinen getrieben durch Anwendungsanforderungen) kann dazu führen dass keine neue Software mehr geladen werden kann. Oft werden auch die Nachteile der Trennung (etwa doppelte Empfangsroutinen) überschätzt, oder die Vorteile (stabiler Bootloader) unterschätzt. LG, Sebastian
Sebastian W. schrieb: > oder die Vorteile (stabiler Bootloader) unterschätzt. Das geht? Mich wundert....
Arduino Fanboy D. schrieb: > Sebastian W. schrieb: >> oder die Vorteile (stabiler Bootloader) unterschätzt. > Das geht? > Mich wundert.... Warum nicht, Vor- und Nachteile kann ja jeder für sich selbst gewichten. Ich hab vor Jahren einen HTTP-Bootloader geschieben (https://github.com/wangnick/httpboot), der durch DHCP und DNS schon recht groß wurde, und hab gerade einen CAN-Bootloader geschrieben der sich selbst ersetzen kann. Ich kann allerdings alle Geräte ohne allzuviel Aufwand jederzeit wieder zusammensammeln und an den Programmierer hängen, falls ich mich aussperren sollte ... LG, Sebastian
Sebastian W. schrieb: > 1. Neue Anwendung und alte müssen gemeinsam gleichzeitig in den > Flashspeicher passen. Ich habe auch schon mal dafür ein 128kB SPI-RAM mit verbaut. Der Code wird erstmal ins SPI-RAM geladen, dann werden Prüfsummen und Signaturen geprüft, und erst dann werden Interrupts gesperrt, die Flash-Routine ins RAM kopiert und dort ausgeführt. > 2. Nach Empfang der neuen Anwendung und Ablage im Flashspeicher muss man > die alte Anwendung durch die neue ersetzen. Dazu braucht es einen > weiteren kleinen Flashspeicherbereich für die dazu nötigen > Instruktionen. Oder man lässt den entsprechenden Code im RAM laufen. Das ist bei vielen Prozessoren anzuraten, wenn der Prozessor dort während eines Lösch-Schreibzyklus keine Instruktionen mehr holen kann und somit blockiert wird. Insbesondere ein Bulk Erase kann bis in den Sekundenbereich gehen. Manche Prozessoren haben separate Bootsektoren, die eine vom Hauptblock unabhängige Programmierlogik haben, aber nicht alle. Bei Havard-Architekturen wie AVR und 8051 geht das natürlich nicht. > 3. Ein Fehler in der Anwendung (z.B. Watchdog-Fehlprogrammierung, > fehlerhafte Fortentwicklung der Empfangsroutinen getrieben durch > Anwendungsanforderungen) kann dazu führen dass keine neue Software mehr > geladen werden kann. Ja, Code sollte man halt vorher testen, bevor man ihn an Kunden rausgibt. Nicht nur deswegen. Ich habe dieses Vorgehen auch schon öfters angewendet, insbesondere wenn der Bootloader durch Ethernet/IP oder wasweißich sehr groß geworden wäre. fchk
Moin, der Titel passt zu meinem Problem. Nachdem ich keine Kabelverbindung zu meinen IR-gesteuerten Modellen realisieren konnte, möchte ich die RC5-Lesefunktion in einen Bootlader stellen um mein Programm zu aktualisieren. Das dauert dann bei 1kB Code ca. 15 min. Bitte um Eure Meinung und Vorschläge, insbesonders zu fertigen Lösungen. Vielleicht kann mich Einer unterstützen, zunächst brauche ich ein Sendeprogramm, mgl. im Raspi. Bisher habe ich nur eine Hand-Fernbedienung benutzt.
My T. schrieb: > die RC5-Lesefunktion in einen Bootlader > insbesonders zu fertigen Lösungen. Das ist ein sehr ungewöhnlicher Ansatz, den wirst du dir wohl selbst bauen müssen.
..möchte ich die RC5-Lesefunktion in einen Bootlader stellen um mein Programm zu aktualisieren. Stefan F. schrieb: > Das ist ein sehr ungewöhnlicher Ansatz, Warum, ist langsam aber keine Kabel nötig. Und gabs auch schon. Rückmelde-LED will ich nur als Signal: Page(s) ohne Fehler übertragen (Ich habe Zeit um zu wiederholen.) Jetzt konkrete Fragen: ATtiny45 hat keinen extra Bootlader-Bereich. Wenn Fuse SELFPRGEN=0 dann kann die zu aktutlisierende Page irgendwo von 0000 bis 03fc0 liegen, je nach Doppelregister Z ? Wo liegt denn der Pufferbereich? Die Codeschnipsel von Peda sind leider unübersichtlich wegen der vielen Typen. Bei http://www.g-heinrichs.de/attiny/Bootloader.pdf ist es schöner. Gibts noch ne bessre Assembler-Vorlage? Zum Senden habe ich außer Lirc kein IR-Sendeprogramm gefunden. Um 256 unterschiedliche Bytes senden zu können brauche ich dann 4 Geräte mit je 64 Tasten, die in die Liste lirc.conf geschrieben werden und die Tastennamen sind frei wählbar, zB x3e ?
Wenn du genügend Platz hast im Flash, und eine Ausfallsicherheit haben möchtest, würde ich empfehlen, den Flash in drei oder 4 Bereiche zu teilen: - Bootloader (an der Startadresse) - Config Area (für feste config Daten) - App 1 - App 2 In der Config Area wird dann festgelegt, welche der beiden App bereiche gestartet werden soll. So kann eine neue FW geschrieben werden, und die vorherige bleibt erhalten. Der Bootloader kann vor dem Starten auch für eine sichere Umgebung (z.B. alles abschalten) sorgen. Eine App würde ich dort aber nicht einbinden.
:
Bearbeitet durch User
Ueblicherweise koennen sich Bootloader nicht ueberschreiben, weil das hardwaremaessig verschiedene Bereiche sind. Vorgegebene Bereiche. Da ist nichts mit beliebig waehlen.
My T. schrieb: > der Titel passt zu meinem Problem. Nö. Die wenigsten lesen mitten im Thread, daß sich das Thema geändert hat. Mach daher nen eigenen Thread auf. My T. schrieb: > Das dauert dann bei 1kB Code ca. 15 min. RC5 sendet mit ~500Bit/s, 1kB sollten also ~16s brauchen.
Ja, das IR-Senden gehört hier nicht hierher. Trotzdem die Richtigstellung:. Die zeitliche Dauer jedes gesendeten Bits beträgt 1,778 ms, die 14 Bits eines Rahmens benötigen 24,889 ms zur Übertragung. Der Datenrahmen wird bei gedrückter Taste alle 113,778 ms wiederholt. (Zitat aus Wikipedia)
Wenn der Bootloader getestet und für gut befunden wurde braucht man sich darum nicht mehr zu kümmern, nutzt ihn einfach. Sollte aber Loader und Application ein Stück sein könnte sich jedesmal auch in den Bootroutinen ein bug eingeschlichen haben, müßte also jedesmal aufwendig getestet werden. Ich nutze beruflich Das U-Boot für Linux. Da gibt es dann gleich mehrere Partitionen wo Kernel und Image doppelt vorhanden sind und nur das Image bei der täglichen Entwicklungsarbeit erneuert wird. Wäre ziemlich teuer wenn z.b. bei Spannungsausfall jemand nach Kanada fliegen müßte um tote Geräte wieder zu beleben. So ist sicher gestellt das der letzte lauffähige Stand wieder bootet wenn beim Flashen was schief geht.
Auch wenn einige hier das als eine "abenteuerliche" Idee ansehen, so bleibt doch - im Interesse eines sauberen Programms - Bootloader eben Bootloader! Der hat eine einzige Aufgabe! Alles was man da noch hinein schreibt, ist dort falsch!!! Und die meisten Controller unterscheiden in ihrem Flash den Bootloader-Bereich vom "normalen" Flash. Warum wohl? Gruß Rainer
Rainer V. schrieb: > Und die meisten Controller unterscheiden in > ihrem Flash den Bootloader-Bereich vom "normalen" Flash. Warum wohl? Weil bei diesen Controllern idR. ein fertiger Bootloader für die Kommunikation per RS232 oder USB im ROM (nicht veränderbar) hinterlegt ist. Siehe z.B. Atmel, NXP. Es ist aber immer eine gute Idee, den eigenen Bootloader für das Firmware-Update (dort ist dann auch der Krypto-Kram mit drin) von der Firmware zu trennen, am besten noch eine weitere, separate Config Area einzurichten. So bleibt die Firmware generisch und kann immer wieder nachinstalliert werden, wenn was schiefgeht. Oder man hat genug Platz für 2 Firmware-Bereiche und schaltet um.
Random .. schrieb: > Es ist aber immer eine gute Idee, den eigenen Bootloader für das > Firmware-Update ... von der > Firmware zu trennen, Eine absolute, vollständige Trennung? Nein ist es nicht. Meistens, ja. Nicht unbedingt einfach zu händeln, ja. Aber "immer"? Nöö... Zwei Gründe seien mal genannt, welche gegen "immer" sprechen: 1: Die Anwendung muss bei einem AVR in das Flash schreiben können. Mag selten vorkommen, geht dann aber nur über den Bootloaderbereich. 2: Vermeiden von Codeduplikaten. Wenn sich denn in der Anwendung und im Bootloader identische Codeteile befinden. Diese können geteilt, bzw. gemeinsam genutzt werden. Auf ein "fast immer" oder "üblicherweise" könnte ich mich einlassen. Aber ein "immer", muss ich ablehnen. Widersprechen.
Arduino Fanboy D. schrieb: > Wenn sich denn in der Anwendung und im > Bootloader identische Codeteile befinden. Diese können geteilt, bzw. > gemeinsam genutzt werden. Das lässt halt alle Sicherheitsaspekte ausser acht. Der Bootloader ist bei manchen Prozessoren ja deswegen extra geschützt, damit ihn nicht ein wildgewordener User überschreibt und damit das Gerät/die Maschine unbrauchbar macht. Georg
Georg schrieb: > Der Bootloader ist > bei manchen Prozessoren ja deswegen extra geschützt, Hää... Wer sprach denn davon, dass sich der Bootloader selber überschreiben soll? Da stehen doch meist/hoffentlich die Lock Fuses im Wege rum. Ich sprach von gemeinsamer Codenutzung. Das bedeutet nicht, dass Bootloader und Anwendung zwingend gemeinsam/gleichzeitig ins Flash gespielt werden müssen. Aber natürlich kann man auch "Bootloader überschreibt sich selber" einstielen, wenn man denn unbedingt will. Ist dann aber noch ein Schwierigkeitsgrad höher. Und wie du richtig erkannt hast, eine Möglichkeit sich versehentlich abzuhängen. Ein ISP Adapter wirds dann wieder richten. Das Verfahren ist eigentlich ganz einfach: Beim Bootloader kompilieren lässt man sich ein map File erzeugen, dort sind die Einsprungspunkte/Funktionen vermerkt. Diese teilt man der Anwendung beim kompilieren mit. Aufpassen, dass die gemeinsam genutzten Funktionen nicht auf ISR angewiesen sind, und keine globalen oder statischen Variablen verwenden. Sonstige "Gegenanzeigen" oder Risiken sehe ich da nicht. Gibt auch von Atmel eine ANxxx dazu, welche das im Detail erklärt. z.B. Forth auf AVR wäre ohne solche Verfahren undenkbar Da muss die Anwendung ins Flash schreiben können. Welches eben nur über den Aufruf von Routinen im Bootloaderbereich erfolgen kann.
Arduino Fanboy D. schrieb: > Beim Bootloader kompilieren lässt man sich ein map File erzeugen, dort > sind die Einsprungspunkte/Funktionen vermerkt. Diese teilt man der > Anwendung beim kompilieren mit. Einfacher ist es, wie bei einem DOS-Interrupt. Man hat eine feste Adresse, z.B. die letzte Adresse im Flash, wo der Einsprung ins Bootloader-API erfolgt. Über ein Register erfolgt dann die Funktionsauswahl.
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.