Kleines Problem mit itoa
Im Unterforum Microcontroller - Beschreibung: Hardware - Software - Ideen - Projekte
| Autor |
|
|
|
BID = 851318
Offroad GTI
Urgestein
Beiträge: 12742
Wohnort: Cottbus
|
|
Zitat :
| | Übersichtlicher als das obige, wahrscheinlich auch noch mit Prüfsummen aufgefüllte Binärformat, ist die Assembler-Darstellung. |
Meinst du das?
Kann es hier nicht direkt hochladen, es kommt eine Fehlermeldung.
Sieht für mich noch schlimmer aus...
(Habe in das Programm noch ein paar Dummy-Berechnungen eingefügt, um zu sehen, wie sich die Dateigröße verändert)
Zitat :
| | Da das ja nur 20 Byte sind, wie du schreibst, |
Nein, die 20Byte sind eine Berechnung. Das ganze Programm ist 1,4kB groß.
Zitat :
| | Wahrscheinlich wirst du mir aber nur ein paar Zubringerbefehle und Unterprogrammaufrufe präsentieren. |
Das war die HEX-Datei, welche in den ATMEGA geladen wurde.
_________________
Theoretisch gibt es zwischen Theorie und Praxis keinen Unterschied. Praktisch gibt es ihn aber.
[ Diese Nachricht wurde geändert von: Offroad GTI am 8 Okt 2012 19:17 ] |
|
BID = 851351
Brizz
Stammposter
Beiträge: 386
Wohnort: Rheine
|
|
Aus dem Maschinen-Code kann man sehen, dass nur einer der vielen Interruptvektoren beschrieben ist. Ich nehme einmal an, dass das der vom AD-Wandler ist. Die freien Vektoren und der Programmstartvektor zeigen auf einen Speicherbereich welcher, nicht zu Deinem Hex-Dump gehört. Hinter dem Vektorbereich liegen Daten, Konstanten und Tabellen-Krams. Das Programm arbeitet bislang ohne Zeitnormal und ohne UART,
sozusagen ohne Herzschlag und Kommunikation zur Außenwelt, abgesehen von den Analogwerten.
Das kann man aus dem HEX-Dump sehen, ohne den Prozessor zu kennen.
Ob ein Programm an einer Stelle zehn oder zwei Bytes mehr braucht, kann dadurch verursacht werden, dass manche Dinge direkt erledigt werden, oder statt dessen ein Unterprogramm aufgerufen wird, was dann in der Regel länger dauert.
Es ist daher immer gut, mal hinter die Kulissen zu schauen, wie der Compiler die C-Anweisungen umsetzt, damit man weiß, ob die Art so oder so zu Programmieren speichersparenden oder schnellen Code generiert, je nachdem wo 's eng wird. Da kann man von Prozessor zu Prozessor böse Überraschungen erleben.
[ Diese Nachricht wurde geändert von: Brizz am 8 Okt 2012 21:22 ] |
|
BID = 851408
perl
Ehrenmitglied
Beiträge: 11110,1
Wohnort: Rheinbach
|
Zitat :
| | Nein, die 20Byte sind eine Berechnung. Das ganze Programm ist 1,4kB groß. |
Dann schmeiss mal die Multiplikation und besonders die Division raus (und achte darauf, dass nicht woanders welche vorkommen) und schreib nur:
uint32_t Umrechnung=ZehnBitWert;
Dann wirst du sehen, wieviel Platz MUL und DIV kostet.
Es kann natürlich passieren, dass die betreffenden Routinen trotzdem eingebunden werden, das ist eine Frage der Optimierung, die der Compiler bzw. Linker vornimmt, - oder eben nicht.
Dein Prozessor kann hardwaremäßig 8x8 Bit multiplizieren, aber viele kleinere können das nicht per se und müssen dafür jedesmal ein Unterprogramm abarbeiten.
Außerdem haben sie vielleicht nur 20 Bytes RAM, mit denen man nicht so verschwenderisch umgehen kann.
Ganz übel würde das, wenn du überflüssigerweise mit genormten IEEE-Gleitkommazahlen hantiertest.
Bei kleinen Prozessoren ist dann plötzlich sämtlicher Platz für Programm und Daten verbraucht und es ist kein Platz mehr für das eigentliche Programm vorhanden.
Außerdem sind sie dann kaum noch schneller als ein Taschenrechner.
Es lohnt sich oft, wenn man bei der Programmierung auf die hardwaremäßgen Gegebenheiten Rücksicht nimmt.
|
BID = 851417
Offroad GTI
Urgestein
Beiträge: 12742
Wohnort: Cottbus
|
Zitat :
| schreib nur:
uint32_t Umrechnung=ZehnBitWert;
Dann wirst du sehen, wieviel Platz MUL und DIV kostet. |
Es bleibt bei etwa 20Byte.
Zitat :
| | Ganz übel würde das, wenn du überflüssigerweise mit genormten IEEE-Gleitkommazahlen hantiertest. |
Au ja. Allein bei einer Gleitkommaoperation reicht der 32k Speicher schon nicht mehr aus...
_________________
Theoretisch gibt es zwischen Theorie und Praxis keinen Unterschied. Praktisch gibt es ihn aber.
|
BID = 851477
DonComi
Inventar
Beiträge: 8605
Wohnort: Amerika
|
Zitat :
| | Allein bei einer Gleitkommaoperation reicht der 32k Speicher schon nicht mehr aus... |
Das halte ich für ein Gerücht.
Die Softwareimplementierung ist bloß knappe 2k groß, abhängig natürlich von ein paar Gegebenheiten, aber über 3,5k kommt man selten.
_________________
|
BID = 851482
Offroad GTI
Urgestein
Beiträge: 12742
Wohnort: Cottbus
|
Ist ja eingenartig, habe jetzt noch mal eine float-Variable eingefügt und es werden nun etwa 3kB benötigt.
Letztens kam aber die Fehlermeldung, dass nicht genügend Speicher vorhanden sei. Naja, wer weis, was ich da für´n Mist eingegeben habe 
_________________
Theoretisch gibt es zwischen Theorie und Praxis keinen Unterschied. Praktisch gibt es ihn aber.
|
|
Zum Ersatzteileshop
Bezeichnungen von Produkten, Abbildungen und Logos , die in diesem Forum oder im Shop verwendet werden, sind Eigentum des entsprechenden Herstellers oder Besitzers. Diese dienen lediglich zur Identifikation!
Impressum
Datenschutz
Copyright © Baldur Brock Fernsehtechnik und Versand Ersatzteile in Heilbronn Deutschland
gerechnet auf die letzten 30 Tage haben wir 19 Beiträge im Durchschnitt pro Tag heute wurden bisher 20 Beiträge verfasst
© x sparkkelsputz Besucher : 182420732 Heute : 5230 Gestern : 7490 Online : 154 28.11.2024 22:55
2 Besucher in den letzten 60 Sekunden alle 30.00 Sekunden ein neuer Besucher ---- logout ----viewtopic ---- logout ----
|
xcvb
ycvb
0.032105922699
|
