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
Ich kanns gerade selbst nicht testen, aber schreib doch mal fix y=(x*100.0)/1024.0; Und guck ob es geht... LG, Björn
unfassbar ..funktioniert, wie kommt den das Zustande ?? 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:-)
<<8 und low byte :-) ich geh jetzt wirklich ins Bett und bin froh, dass ich nicht wirklich was programmieren muss:-)
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
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.