Hallo,
ist es möglich, dass man mit manuellen Eingriffen den Bootloader
vergrößern kann? Ich nutze den ATXmega128A3U und dieser hat 8kb, im
Moment ist mein Programm jedoch 10,2kb groß.
Sollte es funktionieren, wenn ich gezielte Funktionen oder Klassen -
welche keine Flashzugriffe durchführen - außerhalb des
Bootloaderbereiches positioniere?
Dann würde mein Programm normal im Bootloaderbereich anfangen, die ISR
Tabelle wäre ordentlich umgebogen und lediglich ein paar unkritische
Funktionen befänden sich ausserhalb des Bootloaderbereiches.
Sind das Angaben im Linker oder im C++ Code? Wäre das generlel möglich?
Danke!
Nils schrieb:> Sind das Angaben im Linker
Ja, genau dort. Definiere ein Segment für den "Extra" Code und lege es
"nach oben".
> oder im C++ Code
Dem Code ist es egal, wo er ausgeführt wird (wenn man ohne Tricks
programmiert)
> Wäre das generlel möglich?
Ja. Dein Bootlader muss dann nur selbst den Extra Teil schützen, die
Lockbits helfen dir da nicht mehr.
Die unkritischen Funktionen sind waehred des bootloadens aber gar nicht
vorhanden...
Nee. Da gibt's eigentlich nur Eines .. das Programm muss kompakter
werden. Man staunt, wieviel Luft da noch ist. Ich hab einen bootloader
in weniger als 2k geschrieben.
Allenfalls die Interrupts durch Polling ersetzen ?
Allenfalls ein anderes Protokoll verwenden ?
Oh D. schrieb:> Die unkritischen Funktionen sind waehred des bootloadens aber gar> nicht> vorhanden...>> Nee. Da gibt's eigentlich nur Eines .. das Programm muss kompakter> werden. Man staunt, wieviel Luft da noch ist. Ich hab einen bootloader> in weniger als 2k geschrieben.> Allenfalls die Interrupts durch Polling ersetzen ?> Allenfalls ein anderes Protokoll verwenden ?
Mit kritisch meine ich die Funktionen, die den Schreibvorgang im Flash
durchführen. Kann nicht alles andere theoretisch wo anders liegen?
Falls z.B. eine Bibliothek/Funktion/Klasse an eine andere Stelle soll,
wie kriege ich das hin? Definieren und zuweisen?
Entweder diese Funktionalitaet wird im Bootloader gebraucht oder eben
nicht.
Irgendwelcher objektorientierter Firlefanz, dynamisches Memory und
dergleichen gehoert auch nicht in den Bootloader.
Oh D. schrieb:> Entweder diese Funktionalitaet wird im Bootloader gebraucht oder> eben> nicht.> Irgendwelcher objektorientierter Firlefanz, dynamisches Memory und> dergleichen gehoert auch nicht in den Bootloader.
Das sei mal dahingestellt und außen vor. Diese Antwort bezieht sich auf
eine persöhnliche Meinung und ist dem Themenstarter in seiner
Ausgangsfrage nicht hilfreich.
Beginne gedanklich nach den Erase. Deine "unkritischen" Teile sind
gelöscht.
Nun ist es an dir zu überlegen, ob dein Bootloader noch alles das tun
kann, was du von ihm erwartest.
Steffen R. schrieb:> Beginne gedanklich nach den Erase.
Er kann den Speicher Seitenweise löschen und seinen Boot Code aussparen.
Und eventuell wäre auch ein Blick auf den Speicherbereich "Application
Table Section" hilfreich. Der lässt sich sogar separat schützen.
Oh D. schrieb:> Entweder diese Funktionalitaet wird im Bootloader gebraucht oder> eben> nicht.> Irgendwelcher objektorientierter Firlefanz, dynamisches Memory und> dergleichen gehoert auch nicht in den Bootloader.
Ich nehme halte bereits getestete Bibliotheken und setze daraus meinen
Bootloader zusammen. Ja, ist OOP. 3kb zu groß - shit happens, dann
packen ich diese 3kb eben wo annders hin.
Ganz davon abgesehen, dass dynamishces Memory nicht verwendet wird.
Steffen R. schrieb:> Beginne gedanklich nach den Erase. Deine "unkritischen" Teile sind> gelöscht.>> Nun ist es an dir zu überlegen, ob dein Bootloader noch alles das tun> kann, was du von ihm erwartest.
Das kann ich ja selber im Bootloader berücksichtigen - und so gestalten,
dass dieser auf diese zusätzliche kb nicht schreiben darf.
######
Kann ich dem Linker nun irgendwie mitteilen, dass bestimmte Klassen an
einen anderen ort gesetzt werden sollen?
Nils schrieb:> jedoch 10,2kb groß.
Das ist aber ganz schön viel, hast Du vergessen -Os einzuschalten? Sind
Dir irgendwo versehentlich Fließkomma-Routinen reingerutscht? Hast Du
irgendwelche riesigen(!) Arrays mit Daten im Flash?
Zum Vergleich (nur um mal nen kurzen Realitätsabgleich zu machen): Ein
real existierender (mir und anderen hier bekannter) Bootoader für AVR
mit Verschlüsselung(!) in ASM braucht vielleicht 800 Byte. Das rangiert
nahe am Minimum, das ist wohl die untere Grenze.
In C mit der selben Funktionalität würde der selbe Bootloader vielleicht
das doppelte brauchen, maximal vielleicht sogar 2000 Byte, jedoch
keinesfalls mehr. Geht einfach nicht, mehr Substanz ist einfach nicht da
daß das noch nennenswert mehr Platz ausfüllen könnte.
Einen Bootloader für nen ARM mit ähnlicher Funktionalität hab ich hier
am Laufen, komplett in C geschrieben, ohne irgendwelche Verrenkungen,
der braucht so um die ~1700 Byte (UART) oder ~2000 Byte (mit HMT7748
Treiber) Und auch hier nicht etwa weil ich irgendwelche komischen Tricks
anwende, im Gegenteil hab ich an vielen Stellen eher den ausführlichen,
lesbaren Weg gewählt, der Compiler (gcc) spuckt einfach nicht mehr Code
aus, egal wie langatmig und ausführlich ich alles hinschreibe!
Was ich damit sagen will ist:
Irgendwas ist da nicht richtig gelaufen, und zwar ganz und gar nicht,
irgendwas hast Du übersehen, irgendwas ist da reingerutscht was da gar
nicht hingehört, 10kB sind NICHT plausibel für nen simplen Bootloader,
nicht in diesem Universum und auch in keinem anderen. 2k: Ja, 3k: auch
noch OK, 4k: Der kann dann aber schon Kaffee kochen, 10k: No way! Da ist
irgendwas anderes kaputt!
Geh doch mal in Ruhe die .lss Datei durch und schau was der da alles mit
reingepackt hat, das ist der schnellste Weg den Übeltäter zu
identifizieren. Sobald Du was findest was da definitiv nicht gebraucht
wird findest Du auch relativ schnell die Stelle an der Du das
versehentlich mit reinziehst und kannst das abstellen.
Und natürlich nicht zuletzt -Os --ffunction-sections und
-Wl,--gc-sections und -flto sowieso, gerade dann wenn man mit riesigen
fremden libs arbeitet von denen man nur 1% nutzen will.
> Er hat nie behauptet, dass es nur ein simpler Bootloader ist.
Ob das Sinn macht ? Alle Libraries, die fest im Bootloader Teil drin
sind koennen nicht ersetzt werden. Dann wuerd ich eher nur den
Bootloader haben wollen und den dafuer reservierten Bereich verkleinern.
Das muesste man genauer anschauen. Weshalb das so sein soll.
Ich schrieb einen http Bootloader, der hat ueber das Internet gebootet
mit weniger als 2k Code. Allerdings auf lokale Interaktion hin, dh man
musste einen Button im Geraet druecken.
Oh D. schrieb:> Ob das Sinn macht ?
Das war nicht seine Frage.
Aber schon bei einen Standardkonformen CANopen Bootloader gibts mit den
8k Probleme. Je nach notwendiger Funktionalität. Solche komplexeren
Implementierungen sind notwendig, wenn das Gerät für das Update nicht
aus dem Netz genommen werden soll und auch speziell über die normale
Kommunikationsschnittstelle ein Update bekommen soll.
Nur mal so als Beispiel. Ohne eine Diskussion lostreten zu wollen, dass
es hier einige Experten gibt, die es gut hinbekommen.
Hier sollte es um den TE gehen und der macht keine genaueren Aussagen,
warum sein Code so groß ist und fragt auch nicht nach Unterstützung,
seinen Code kleiner zu machen. Aus meiner Sicht wäre es bei dieser
Fragestellung auch nicht so ungewöhlich danach zu fragen, sollte er es
wünschen.
