Mahlzeit!
Im ersten Wurf ein Problem zu lösen entsteht ja erstmal etwas
Funktionierendes. Tut es auch. Aber leider explodiert mir der Code auch
inzwischen an die Grenzen der 64kb zusammen mit der SD Karten Verwaltung
und einer Grafik Library fürs Display, da im Debug Mode keine
Optimierung erlaubt ist.
Grund: Für das Rechnen mit Geokoordinaten und deren Umwandlung muss ich
float Libs einbinden, float selbst und leider auch Sachen wie sprintf -
Float für die Display ausgabe.
Im ersten Schritt versuche ich sprintf(float..) zu vermeiden durch
Umwandlung von float in Strings, die mit im Ram liegen. Davon habe ich
noch genug. Das hat mir 7kb Code Size gespart, da ich die nano lib für
printf nicht mehr einbinden muss.
Jetzt bleiben noch so Kracher wie atof und einge andere. Verwendet man
eine Funktion bindet der Linker das ganze Modul der nano-branch Lib ein
mit allen was dazu compiliert wurde. Denn die liegt nur als objekt Code
vor. Und das Ding sind mal eben so ca 15kb.
Frage: Wo finde ich die Sourcen dieser String Funktionen aber auch
anderer aus der stdlib. stdio usw, dass ich die vielleicht direkt in den
Code holen kann?
Christian J. schrieb:> ...da im Debug Mode keine Optimierung erlaubt ist.> ...muss ich float Libs einbinden> ...Verwendet man eine Funktion bindet der Linker das ganze Modul der nano-branch
Lib ein
Du solltest mal den Chef wechseln, wenn der immer meint du "must"
irgendwas machen, auch wenn es eventuell keinen Sinn macht:-)
Wenn es ein eigenes Projekt ist lautes das höchstens "ich will" dies und
das verwenden.
Im debugmodus darf man erstmal tun und lasen was man will, da gibt es
keine Gesetze (höchstens Chefs) die einem sowas verbieten. Auf maximum
Optimieren kann natürlich dazu führen, dass man sich gewaltig ins Knie
schießt, weil man im erzeugen Assemblercode nichts mehr aus seinem
ursprünglichen Code wiedererkennt.
Aber das Thema betrifft sowohl den Compiler als auch die Linke und bei
beiden kann man in der Regel recht genau einstellen welche Optimierungen
gemacht werden sollen und welche nicht. Geht halt nur mit Bandwürmern
und nicht mehr so schön mit -Ox. Gerade dem Linkem sagen das er alle
unbenutzte rausschmeißen soll kann hier durchaus sinnvoll sein, weil
diese Teile auch beim Debuggen nie verwendet werden.
eine Funktion die einem irgendwas in eine Bildschirmausgabe umwandelt
kann man sogar mal selber schreiben. Geht meist schneller als lange was
zu suchen und ist meist übersichtlicher, weil es eben nur das beinhaltet
was man auch wirklich benötigt und keine Eierlegendewollmischsau ist wie
z.B. printf.
Programmieren ist nicht immer nur irgendwelche Teile zusammen zu
kopieren.
Und mit etwas überlegen kann man vieles von dem float Zeugs auch mit
integern ausreichend darstellen...
Jim M. schrieb:> eraltet.>> Optimierung -Og existiert schon ewig im GCC.
Danke,das hilft mir schon weiter! Kann ja nicht alles wissen :-) Hat 9kb
eingespart und zur Not muss eben der 64kb F103 einem 128kb Typ weichen.
Christian J. schrieb:> zur Not muss eben der 64kb F103 einem 128kb Typ weichen
Der F103C8 hat sowieso immer 128kB Flash, es sei denn, es ist ein
China-Klon, z.B. CKS32.
Ich gebe aber meinen Vorpostern recht: Man muss nicht über jedes
Stöckchen springen, was einem von irgendeiner Entwicklungsumgebung dahin
gehalten wird.
Christopher J. schrieb:> Der F103C8 hat sowieso immer 128kB Flash
Es gibt nur inoffizielle 128kb. Die kannste aber nicht nutzen mit
st-link. Das geht nur mit openocd. Denn st-link fragt die Chip ID ab und
daraus bestimmt sich der Wert. Dass dasein Klon ist davon gehe ich stark
aus, aber er tut es wie er es soll.
Unbenannt.JPG
(58 KB)
