www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ADC LCD Darstellung und seine Problemchen


Autor: Alex Haas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn R. (sushi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex Haas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unfassbar ..funktioniert, wie kommt den das Zustande ??

Gruß Alex

Autor: Björn R. (sushi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex Haas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn R. (sushi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cast ist dein Freund :-)
y=(long) x*100/1024;

Autor: Björn R. (sushi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex Haas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und noch einfacher:
y=x*50/512;

Autor: Björn R. (sushi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex Haas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:-)

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<<8
und low byte :-)
ich geh jetzt wirklich ins Bett und bin froh, dass ich nicht wirklich 
was programmieren muss:-)

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Roland Praml (pram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex Haas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.