Hallo
Jungs, habe ein Programm geschrieben, der mir 3 spannungegn misst und
diese in einer Berechnung einbezieht und anschliessend an PC übertrage.
nun habe ich ich eine schwankende Messung, mal richtig mal falsch,
obwohl meine Eigangsspannungen alle relativ konstant sind.
Nun habe ich die Bitte, ob jemand mal schauen kann, ob ich den
integreirten Adc richtig verwende, besonders ob die Anweiseung für den
ADMUX in der richtigen Stelle steht.Wäre auch dankbar für Andare
Hinweise bezüglich des Programms.
Das Programm findt ihr im Anhang, ich verwende ein Atmega88
Danke im Voraus
Pedro
Hallo!
Mein erster Gedanke war die Übertaktung des ADCs. Der Teiler steht auf
32, was bei den im Quelltext angegebenen 3,072MHz richtig gewählt ist.
Allerdings ist diese Frequenz ziemlich exotisch. Prüfe deshalb bitte
zuerst, ob Du wirklich diese Taktung benutzt und nicht etwa den internen
RC-Oszillator mit 8MHz, denn damit würdest Du übertakten und ein
instabiles Wandeln provozieren.
Gruß - Wolfgang
Hi
>was bei den im Quelltext angegebenen 3,072MHz richtig gewählt ist
Ist eine 'handelsübliche' Frequenz.
Wo kommen die Spannungen her? Quellimpedanz?
MfG Spess
Ich glaube nicht , ob das was mit der Quellimpedanz zu tun hat,da ich
meine alte baugruppe auch an der gleichen spannungsversorgung
anschliesse und es funktioniert.
Wie sieht deine Schaltung aus? Was hast du mit AREF gemacht?
Was bedeutet 'relativ konstant'?
Hast du dir schon mal die ADC Werte direkt ausgeben lassen, ohne
Umrechnung? So wie du sie vom ADC erhältst.
Du rechnest da
a=1-(((Vml/Vms2)-1)/((Vml/Vms1)-1));
b=((Vml/Vms2)-1)*((1/(Rsa*((Vml/Vms1)-1)))-(1/Rsi));
c=((Rma*Rsa*((Vml/Vms2)-1))-Rsi*Rsa-Rsi*Rma)/(Rsi*Rma*Rsa);
t=b+c;
Rka=a/t;
ziemlich blauäugig drauf los.
Hast du schon versucht, ob du mathematisch diesen Formalismus noch
vereinfachen kannst? Dinge zusammenziehn, Brüche auflösen, Doppelbrüche
auflösen etc. Solange bis du alles in nur einer Formel beisammen hast.
Floating Point rechnen ist wie das Umschaufeln von Sand.
Mit jeder Operation verliert man ein bischen Sand und gewinnt ein
bischen Schmutz dazu. Je weniger Operationen, desto reiner bleibt der
Sand.
@Karl Heinz Buchegger
hast recht, auf den ersten Blick sieht das ziehmlich wuest aus.
Beim naeheren hinschauhen, sieht man das es schon zusammengefasst und
c-Code optimiert ist.
@Anfänger
Das Datenblatt sagt, so in etwa, dass man nach Aenderungen am MUX
(Kanalwechsel) die erste Messung wegschmeissen soll.
So wie Du das machst, beziehst Du den Muell nach der Kanalumschaltung
mit in Deine Mittelwertberechnung ein.
Keine Ahnung ob das bei 18 Messungen ins Gewicht faellt.
anderer Tip: bei 2^x Messungen reicht ein >> (right shift) fuer die
Division.
Ju
Juergen G. schrieb:> @Karl Heinz Buchegger>> hast recht, auf den ersten Blick sieht das ziehmlich wuest aus.>> Beim naeheren hinschauhen, sieht man das es schon zusammengefasst und> c-Code optimiert ist.
Ich weiss nicht, wie und wo du dir das angesehen hast. Aber diese
Variablen sind durchgehend double und volatile. Wenn der Compiler da
grossartig optimiert dann ist er fehlerhaft. Denn genau das darf er
nicht.
> anderer Tip: bei 2^x Messungen reicht ein >> (right shift) fuer die> Division.
Der Tip mit der 2-er Potenz ist gut. Aber den Shift lass besser den
Compiler ersetzen.
Juergen G. schrieb:> Missverstaendnis>> Das C-Code optimiert bezog sich auf die Formel, nicht auf die Wahl der> Variablen.
Ähm, das hängt zusammen.
Der Compiler darf die Formeln nicht verändern und zb gleiche Ausdrücke
zusammenziehen, eben WEIL die Variablen alle volatile sind.
oben geschriebenes bezog sich auf folgende Aussage von Dir.
[schnipp]
>> ziemlich blauäugig drauf los.> Hast du schon versucht, ob du mathematisch diesen Formalismus noch> vereinfachen kannst? Dinge zusammenziehn, Brüche auflösen, Doppelbrüche> auflösen etc. Solange bis du alles in nur einer Formel beisammen hast.
Ju
