Hallo! Als "überalteter" Rentner interessiert mich die Antwort auf die folgenden Fragen: Hat jeder Mikrocontrollertyp einen eigenen Bootloadertyp/ausführung und besteht die Möglichkeit hier eine "Vereinfachung" durch eine "gewisse Angleichung"? mfG, hans
Nein, es können nicht alle ein Update. Bei vielen reicht der Speicher nicht. Andere können gar nicht mit anderen Rechner reden. Die das können haben hundert verschiedene Übertragungswege …
Hans-Dieter T. schrieb: > Hat jeder Mikrocontrollertyp einen eigenen > Bootloadertyp/ausführung und besteht die Möglichkeit hier eine > "Vereinfachung" durch eine "gewisse Angleichung"? Der Bootloader ist eine Software, die in den Flashspeicher des Controllers geschrieben werden muss. Als Bootloader kannst du aufspielen, was du möchtest.
Hallo Wolfgang, d.h., es gibt keinen eigenständigen Bootloader für jeden Mikrokontroller (typgebunden?) Wonach richtet sich dessen Auswahl (Bootloader)? Gibt es Fachliteratur über Grundsätzliches zum Bootloader in Verbindung mit dem Mikrocontroller? mfG, hans .
Hans-Dieter T. schrieb: > Wonach richtet sich dessen Auswahl (Bootloader)? Es richtet sich nach der Flash-Größe. Einen Controller mit 1KB Flash hat gar kein Platz für einen Bootloader bzw. der wäre größer als die mögliche ANwendung. > Gibt es Fachliteratur über Grundsätzliches zum Bootloader in Verbindung > mit dem Mikrocontroller? Was möchtest du wissen? Die Bootloader-Funktionalität ist in den Datenblättern der Controller beschrieben.
Hans-Dieter T. schrieb: > d.h., es gibt keinen eigenständigen Bootloader für jeden > Mikrokontroller (typgebunden?) Richtig, meist(?) gibt es einen besonders schützbaren Speicherbereich im Flash-Speicher des µC, wo der Bootloader-Programm reingeladen wird. Dieser Bereich wird dann nicht gelöscht, wenn man das normale Programm überschreibt. Die Größe lässt sich oft auch einstellen. Oft tut man sich aber keinen Gefallen, wenn man ohne besonderen Grund z.B. von bewehrten Standardprotokollen für die Kommunikation mit dem Hostrechner abweicht. > Wonach richtet sich dessen Auswahl (Bootloader)? Nach den Anforderungen, die man an ihn hat und nach der Größe des Speicherplatzes, den man für den Bootloader erübrigen kann ;-) Es ist z.B. sicher ein Unterschied, ob man einen µC über eine serielle Schnittstelle an einen PC angebunden hat, oder ob es um ein OTA Update von der Software auf einem Satelliten geht.
Hallo STK500, hallo Wolfgang! Vielen Dank für Eure, für mich hilfreichen Antworten! Ich bin absolut fachfremd (Schiffsmaschinenbau) doch der Transistor, Mosfet und nun der Mikrocontroller haben mich durch ihren Aufbau und Verwendungsmöglichkeiten unwahrscheinlich interessiert und mich auch ein wenig neugierig gemacht, daher meine etwas naiven Fragen! Euch nochmals besten Dank, mfG hans .
Moin, Hans-Dieter T. schrieb: > Ich bin absolut fachfremd (Schiffsmaschinenbau) Na, dann ist doch vielleicht "das U-Boot" https://www.denx.de/wiki/DULG/Manual genau der richtige Einstieg in Bootloader ;-) Gruss WK
Hallo Dergute W!, so einen guten Hinweis von dir hätte ich nie gefunden ! Da "Linux" (Lubuntu) mir nicht fremd sind, scheint dieser Beitrag von dir für mich genau der Richtige zu sein! Nebenbei, ich war UBoot tauglich (Marine), nur meine Körpergröße von 1,94 m hat das verhindert, da dort bei 1,90 m (evtl. 1,91 m) absolut Schluss ist! Nochmals vielen Dank, hans .
Moin, Gerne; uboot ist halt schon das Dickschiff unter den Bootloadern, fuer "dicke" Mikrocontroller. Also z.b. mit Ethernet, Festplatten, etc. "Mikrocontroller" ist da ein weiter Begriff. Auf einem attiny13a wirds kaum sinnvoll sein einen Bootloader zu verwenden, auf einem dicken SoC kanns sein, dass 3 verschiedene Bootloader hintereinander durchlaufen werden, und erst der 3. bootet dann z.b. ein Linux... Gruss WK
Hallo Hans-Dieter, Hans-Dieter T. schrieb: > Wonach richtet sich dessen Auswahl (Bootloader)? in der Regel an den Anforderungen, an den Bootloader / die Update-Möglichkeit des Systems. > Gibt es Fachliteratur über Grundsätzliches zum Bootloader in Verbindung > mit dem Mikrocontroller? Ich habe mal eine Check-Liste erstellt, bei der man mal abprüfen kann, welche Eigenschaften der gewünschte Bootloader haben sollte: https://www.torrox.de/2020/10/16/a-bootloader-checklist/ Viele µCs bieten auch Möglichkeiten, Firmware in den Controller zu bringen, die dann aber in der Praxis nicht genutzt werden können. Z.B.: Controller, bei denen Du zwar einen Firmware-Update über den CAN-Bus machen kannst, dazu aber einen externen Pin auf einen bestimmten Level ziehen musst. schöne Grüße Torsten
Hallo Torsten! Vielen Dank für Deine umfangreiche und vor allen Dingen hilfreiche Antwort auf meine Anfrage hin! Weil ich darin nicht nur eine sehr gute und auch fachliche Unterstützung fand, sondern fast schon eine "soziale Komponente" dazu entdecke, bedanke ich mich, als "uralt Opapa", auch dafür! Als neu Angemeldeter hier im Forum, war ich insgesamt über die mir zuteil werdende Unterstützung von Euch sehr erfreut, zumal ich mich hier als absoluter Laie zu Wort gemeldet hatte! Nochmals vielen Dank, mfG, hans .
Hans-Dieter T. schrieb: > Hat jeder Mikrocontrollertyp einen eigenen > Bootloadertyp/ausführung Nein. Ob ein MC einen Bootloader hat und welchen Funktionsumfang dieser hat, verrät das Datenblatt des jeweiligen MCs. Oft gibt es weitere Dokumente, die den Bootloader beschreiben, z.B. wie er aktiviert werden kann. Z.B. der AT89C51RC läßt sich nur im Programmiergerät programmieren. Aber der AT89C51RC2 hat einen Bootloader über die UART. In der Regel sind die Bootloader verschiedener Hersteller nicht kompatibel und nichtmal die der verschiedenen Serien eines Herstellers. Es gibt auch MCs, die nur in-application programming (IAP) beherrschen, d.h. man muß erst initial einen Bootloader hinein programmieren. Ältere MCs haben oft keinen Bootloader, die muß man in ein Programmiergerät stecken und vorher mit UV-Licht löschen. Oder man muß extern einen programmierten Flash ranpappen.
:
Bearbeitet durch User
Dergute W. schrieb: > auf einem dicken SoC > kanns sein, dass 3 verschiedene Bootloader hintereinander durchlaufen > werden Das hatte ich mal für einen DS80C320 gemacht. Zuerst wurden 128 Byte Truth-Table aus einem PZ5064 CPLD nach 0x0000 gemappt und ausgeführt. Diese haben dann am oberen Ende 4kB aus einem 24C512 EEPROM in den SRAM gelesen und angesprungen. Diese haben dann weitere Bootloaderfunktionen und die Applikation nachgeladen. Wurde nach einiger Zeit nicht über CAN die Bootloaderfunktion aufgerufen, wurde wieder nach 0x0000 gesprungen, diesmal aber in den SRAM und damit die Applikation gestartet.
Moin, Ja, ich erzaehl keinen Scheiss. Sowas gibt's. 2 stufig hatte ich das erste Mal, irrc bei TI; diesem Prozessor aufm Beaglebone. Da ist das OnChip RAM zu klein, um ein komplettes uboot zu fassen und's externe DRAM geht noch nicht, weil der DRAM Controller erst noch initialisiert werden muss. Da wird dann ein "mini-uboot (MLO)" dem eigentlichen uboot vorgeschaltet. Und ein aehnliches Konstrukt noch mit einem signaturpruefenden ur-bootloader on Chip gab's bei einem SoC aus dem fernen Osten. Da waren's dann also 3, bevor der Kernel losgeht... Naja, solange das alles funktioniert, kriegts keiner mit. Es geht ja alles recht zuegig am Anfang. Gruss WK
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.