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?
1 | -section-start=TestSec=0x200 |
2 | |
3 | __attribute__ ((section (".TestSec")))
|
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?
Das Manual zum Linker hast du studiert ? Koennte der eine statische Allozierung von Code ?
Jens schrieb: > Kann ich dem Linker nun irgendwie mitteilen, dass bestimmte Klassen an > einen anderen ort gesetzt werden sollen? Vielleicht hilft dir das: http://www.atmel.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_reloc_code.html
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.
:
Bearbeitet durch User
Bernd K. schrieb: > 10kB sind NICHT plausibel für nen simplen Bootloader Er hat nie behauptet, dass es nur ein simpler Bootloader ist.
> 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.
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.