Habe mit meinem STK525 und AT90USB, einen AD-Wandler in Betrieb, der die
Werte dann über RS232 ans HYper Terminal sendet.
Was ich komisch finde:
1. die Werte stimmen nicht mit den gemessenen Werten überein
2. die Abweichungen sind nicht konstant
hier ein paar Beispiele:
Multimeter AT90USB Differenz
2791mV 2244mV 547
3209mV 2586mV 623
3824mV 3110mV 714
4243mV 3460mV 783
Kann es sein, dass es was mit der Umrechnung Digitalwert in
Spannungswert zu tun hat(Rundungsfehler..?)
hier mein Code: val=val*(5000/1023);
itoa(val,string,10);
Vielleicht hatte ja schon jemand ähnliche Probleme!
MfG Thorben
@ Thorben (Gast)
>Kann es sein, dass es was mit der Umrechnung Digitalwert in>Spannungswert zu tun hat(Rundungsfehler..?)
Kann sein.
>hier mein Code: val=val*(5000/1023);> itoa(val,string,10);
Erst alle Multiplikationen, dann erst dividieren.
Festkommaarithmetik
MFG
Falk
@ Thorben (Gast)
>wenn ich erst multipliziere komm ich aber außerhalb meines>Wertebereichs!>val ist bei mir eine 16bit Variable.
Schon mal was von Zwischenergebnissen gehört? Ne 32 Bit variable ist fix
angelegt.
MFG
Falk
Thorben wrote:
> wenn ich erst multipliziere komm ich aber außerhalb meines> Wertebereichs!
Ja, aber val*4 liefert trotzdem das falsche Ergebnis. Du wirst Dir also
was anderes einfallen lassen müssen. Außerdem fehlen Dir anscheinend
einige Grundlagen, was Arithmetik mit Integer-Werten angeht. Falk hat ja
den Artikel zur Festkommaarithmetik bereits angeführt. Allerdings
scheint Dir auch nicht klar zu sein, dass eine Division zweier
Integer-Werte auch einen Integer-Wert zurückliefert. Außerdem musst Du
bei einer Division selbst für eine Rundung sorgen. Sonst gibts nur den
ganzzahligen Teil zurück (und deswegen ist 5000/1023 auch 4 und nicht
5).
GSP wrote:
> Weshalb div 1023 und nicht div 1024, das waere ein stueck einfacher ?
Das kommt noch hinzu. Die effektive Abweichung wäre unter 1 Promill...
Thorben wrote:
> wenn ich erst multipliziere komm ich aber außerhalb meines> Wertebereichs!> val ist bei mir eine 16bit Variable.
macht ja nichts.
Du musst nur dafür sorgen, dass die Berechnung nicht 16 Bit
sondern 32 Bit ausgeführt wird. Das Ergebnis ist ja dann wieder
16 Bit.
C-Regel: Ist einer der Operanden in einer Berechnung ein
32 Bit Wert, dann wird auch der andere zu einem 32 Bit Wert
und die Berechnung wird als 32 Bit Arithmetik ausgeführt.
Genau das machst du mal, indem du die 5000 zu einem long
machst.
1
uint16_tval;
2
3
val=(uint16_t)((val*5000UL)/1023);
5000 ist in 32 Bit, also wird auch val zu 32 Bit
hoch-'gehoben' und die Multplikation wird als 32 Bit Mult.
ausgeführt. Für die Division steht dann links ein 32 Bit
Zwischenergebnis und rechts eine 16 Bit Zahl. Diese wird
daher ebenfalls auf 32 Bit hoch-'gehoben' und die Division
in 32 Bit durchgeführt.
Das Ergebnis aus der ganzen Berechnung hat daher dann auch
32 Bit. Da wir aber wissen, dass es vom Wertebereich her
auch in 16 Bit passen wird, casten wir das mal zurecht
und weisen zu.
Hallo,
ich habe jetzt die Umrechnung soweit im Griff, jedoch weichen die Werte
doch noch immer erheblich vom eigentlichen Wert ab, und bei höherer
Spannung wird auch die Sp.-differenz/der Fehler größer.
Habe den Eingangspin mal auf Masse gelegt, um zu sehen ob es einen
Offset gibt, der ist aber gerade mal 5xLSB, also kann's daran ja nicht
liegen.
Das Verwundernde, danach zeigte mir der Controller die korrekte Spannung
an..., kann es sein dass sich der irgendwie nach einiger Zeit auflädt,
oder so, und das Ergebnis verfäscht?
Gruß Thorben
Beschaltung...
Ich verbinde den Eingangspin mit einem Spannungsteiler(mit Poti) und
einer Batterie, und das wars auch schon.
Hab's gerade wieder probiert und es gibt schon wieder Abweichungen,
obwohl ich nichts geändert habe, und gestern funktionierte es noch gut.
Wie kann das sein / Was ist da falsch ?
Und den Pin kurz auf Masse legen bringt es doch nicht!
Ich brauche bitte dringend Hilfe!
Gruß Thorben
Ja, ist sie.
Ich messe auch direkt am Pin die Spannung die reingeht, aber das
Terminal gibt einen anderen Wert aus.
Könnte das evtl. an irgendwelchen Störungen liegen(elektromagn.
Strahlung...) die auf den Controller einwirken?
MfG Thorben
Nur so zur Sicherheit:
hast du den richtigen Eingangspin benutzt? Ich meine den, an dem du
misst.
Durch Übersprechen auf einen offenen Nachbarpin (an dem gemessen wird)
kann das passieren.
Der Pin ist der Richtige, und die Rohwerte sind auch OK(also an der
Umrechnung liegt es nicht).
Ich habe gerad an den benachbarten Pins mit einem DMM gemessen;
an drei Pins liegt Betriebsspannung, ob die darauf eine Auswirkung
haben?
Aber ich glaube die kann man auch nicht abstellen.
Auf dem STK525 sind die PortPins vom AD-Wandler u.a. auch die
Schnittstelle für ein JTAG-Interface.
Ich weiß wirklich nicht mehr weiter...
Du beschreibst da seltsame Effekte. zb.
> Habe den Eingangspin mal auf Masse gelegt, um zu sehen ob es einen> Offset gibt, der ist aber gerade mal 5xLSB
5xLSB ist schon heftig.
Wenn du den Pin auf Masse legst, dann müsste der Eingang wie
angenagelt auf 0 stehen.
Also: Schaltbild, ev. Foto vom Aufbau, Programm
Ansonsten ist das alles ein Stochern im Nebel.
Das mit den 5LSB war auch ein Irrtum.
Habe jetz mal den Aufbau angehängt, ist wohl nicht optimal, sollte aber
seinen Zweck erfüllen, ich weiß auch nicht genau, was man beachten muss.
hier meine Umrechnung:(10bit Wandler)
adc_val=(U16)((adc_val*((U32)50000))/1023);
Ich hoffe ihr könnt damit was anfangen..
Thorben
Ich denke die Qiderstände im Spannungsteiler sind zu groß im Verhältnis
zum internen R aus dem RC vom AD. Wenn das der Fall ist, musst Du
"langsamer" messen. Also mal den Takt vom ADC absenken, bzw Teiler
erhöhen.
