Moin moin ,
vielleicht kann mir grad zufällig jemand mit meinem Problemchen
helfen...
Es geht um folgendes:
Thema ADC, mit Atmega 8, F=3,686400Hz..
Habe bisher ein Poti mit 0-5V und einer Uref von 5V angeschlossen.
Nehme einen der 10bit Wandler also 1024er Auflösung.
Die Werte sprich 0-1023 lassen sich auch prima auf dem LCD darstellen..
Mein Problemchen..
Ich wollte einfach mal fix hergehen und mir die Werte in % darstellen
lassen..
Sollte ja eigentlich kein Problem sein dachte ich..also habe ich
den ermittelten Wert, nennen wir in "x" einfach mit 100 multipliziert
und durch 1024 geteilt..anschließend ausgegeben.
Rein rechnerisch sollte das wunderbar funktionieren..aber komischerweise
zeigt mir das LCD die Werte 0-64% an springt danach auf 0% und geht den
Rest des Potis bis 25% hoch..
Warum??
Formel schaut so aus: y=(x*100)/1024;
wenn ich einfach mal y=100 eingebe kann ich diese auch wunderbar
darstellen.
ALso die LCD Routine scheint kein Prblem zu sein..
Auch wenn ich verschiedene andere Rechnungen durchführe kann ich die
Ergebnisse darstellen..
Nur bei der richtigen Prozent Darstellung bockt der Controller..;)
Vielleicht seh ich grad vor lauter Bäumen den Wald nicht mehr..daher die
Frage.
Bei interesse poste ich gern auch mal meinen Quelltext.
Hätte da noch ein Interessantes Phänomen ..aber alles der Reihe nach
Vielen Dank im Vorraus und SChönen Gruß Alex
Für eine hoch wissenschaftliche Darstellung des Problems frag wen
anders, oder mich morgen nochmal, dazu passt die Uhrzeit nicht ;-)
Jetzt gerade mal huschi puschi geantwortet:
Der Compiler schneidet dir da was ab, weil deine Konstanten ohne das .0
den falschen Datentyp haben. Damit rechnet er dann weiter...
LG, Björn
Das ist die 1.1000.1111.1001.1100 Zahl die du maximal haben kannst also
1023 * 100 wenn du mit 16Bit Variablen rechnest ist das aber leider eine
zu wenig. Zähl mal die Bits sind genau 16+1 = 17 du verlierst alles ab
etwa ADC Wert 655.
Ne größere Variable oder aber irgendwie die Rechnung ändern
Gruß ErgoProxy
ok..einziges Problem ist nur noch ..ich brauch durch diesen "kleinen "
Schritt fast 3 mal soviel Programm Flash ..das ist n bisschen
unpraktisch ..oder kann das noch an schlechter Syntax liegen ?
Danke schon mal .;)
Antwort reicht auch morgen früh ;)
In diesem Sinne
MFG Alex
Das kommt durch die Division mit den double-Werten. Dein compiler
rechnet die Konstanten ja vorher schon aus, im Grunde steht da also
nichts anderes als y=x*0,09765625. Je nachdem wie genau du es brauchst,
kannst du natürlich den wert runden und einfach y=x/10 schreiben. Dann
bist du wieder bei deinen Integer-Operationen.
Ähm, was mir in diesem Moment auffällt, versuch mal die Klammern
wegzulassen und die beiden .0
LG, Björn
das brauchst du an der stelle aber nicht mehr nach long casten, das
ergebnis passt ja wieder in nen integer rein. Ich würde sagen, das
Problem sind die Klammern, die hindern den Compiler daran, das vorher
auszurechnen.
ähm und jetzt geh ich ins bett... habt ihr mal auf die uhr geguckt???
ich treff die shift taste schon nicht mehr...bitte das zu entschuldigen.
hm also mit weglassen der Klammern und der .0 hab ich zwar wieder
weniger Speicherverbrauch..dennoch zeigt er mir in Endstellung 35% an..
Die Klammern sind also nicht das Problem ..
Aber mit.0 hab ich sowohl mit als auch ohne Klammern genau das
gewünschte Ergebnis.
ist wirklich spät, aber ich glaube schon, dass meine Lösung richtig ist.
Die Berechnung wird mit long durchgeführt (ist ja auch nötig),
anschliessend bei der Zuweisung nach y wieder auf 16bit abgeschnitten.
kürzen kann ich auch ;-)
y=x*25/256;
Sollte mich aber wundern, wenn das das Problem löst. Der Wert wird ja
vorher durch den Compiler berechnet. mit y=x*25/256.0 wirds wieder
genau, aber gibt auch ein großes programm.
So jetzt aber gute Nacht! Und wehe ihr habt morgen wenn ich hier
reingucke die optimale Lösung noch nicht ;-)
abo
Ja ich muss dir Recht geben ..trotz der späten Stunde ..
Die Anzeige läuft mit (long) und ohne Klammern und .0 wunderbar..
und außerdem ist der Speicherbedarf wieder wunderbar klein ;)
Vielen Dank euch und jetz ne wohlverdiente Gute Nacht !!
GRuß Alex
oder
y=(x*25)>>8;
wahrscheinlich noch schneller mit ner union. Als int reinschreiben
(x*25), nur das high-byte zurücklesen.
Lösungen gibts immer viele:-)
Der Speicherbedarf scheint an einem Fehler im neueren GCC zu liegen im
Zusammenhang mit float Variablen. Stand schon in einigen Treads, sowie
auf der Website des GCC.
Gruß ErgoProxy
der Speicherbedarf bei Float liegt ganz einfach daran, das der AVR ein
8bitter ohne FPU (Floating point unit) ist und beim Verwenden von Floats
diese Berechnungen in Software durchgeführt werden müssen.
Eine Float-Rechenoperation dauert auch um ein Vielfaches länger als auf
Ganzzahlen.
Sobald irgendwo im Code ein Float vorkommt, bindet der GCC dafür extra
Code ein, so dass das Prog gleich mal "riesig" wird.
Deshalb: Floats soweit wie möglich und es sinnvolle Alternativen gibt
auf AVR's vermeiden.
Gruß
Roland
Guten morgen und vielen Dank für die vielen Antworten ..vorallem so so
später oder früher Stunde ;)
Problem hat sich Dank der zahlreichen Hinweise und Tipps jetzt gelöst
und der Speicher ist auch minimiert
Schönen Tag und bis zur nächsten Frage;)
Gruß Alex
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
