C: Berechnung fehlerhaft?

wie ist e definiert?

Dirk F schrieb:
> Habe die varriablen zum Testen durch Konstanten ersetzt.

Wenn man jetzt wüßte, was an der Ganzzahlrechnung wirklich variable 
Größen sind, könnte man auch über sinnvolle alternative Formulierungen 
nachdenken, um explosionsartige Anforderungen an die Zahl der gültigen 
Bits in der Rechnung zu vermeiden.

(2^15 -1)/(2^16 -1) ist 1/2 mit einer Abweichung von 7ppm oder einer 
Unsicherheit auf dem 16ten Bit. Der DAC ist ja bestimmt fehlerfrei, 
oder?

Hallo,
das ging ja schnell mit den Antworten.

Die Platform ist PIC32  mit dem XC32 compiler.
Ich denke, INT ist da 32 Bit und long 64 Bit  ?

Das Problem:
Der 24 Bit wert vom DAC  (Skaliert auf 0...2000000) soll mit 
Sollwertvorgabe vom 16 Bit DAC (Bereich 0....65535) verglichen werden.
Also muss ich ja erst eine der beiden Werte auf den anderen Bereich 
skalieren.

Hier der aktuelle code in Textform:

1

          e =  (long) 900000 - (((long) 32767 * (long) 2000000 )/ (long) 65535 ) ; // ( ( voltage <<16) /2000000)  - 32000; //data  ;     // Regeldifferenz = Istwert - Sollwert

2

                if ((e > 1) && (PI_corr > -650)) PI_corr -- ;             // um 1 Digit vom 16-Bit DAC korregieren

3

                if ((e < -1) && (PI_corr <  650)) PI_corr ++ ;             // wird ausgef max 1 % in 6,5 s ausregeln

--

Und das nächste Mal liest Du auch noch den Text, der über dem 
Eingabefeld steht, und verwendest die [ c ] [ /c ] -Tags, dann kann man 
den Kram .. naja .. besser lesen.

-rufus

sorry, meine: ...Der 24 Bit wert vom ADC

HI, habe den Fehler gefunden.
long ist 32 Bit, long long ist 64 Bit...

Danke an alle !!!! uper forum hier.

Dirk F schrieb:
> Der 24 Bit wert vom DAC  (Skaliert auf 0...2000000)

Blöde Idee.

Die Sache wird aber einfacher, wenn du 65536 auf 2000030 oder 2000031 
skalierst. Und der Genauigkeitsfehler verschwindet im 
Digitalisierungsrauschen vom 16-Bit ADC.

> Hier der aktuelle code in Textform:
Du darfst das gerne mit "pre" taggen.

>
>           e =  (long) 900000 - (((long) 32767 * (long) 2000000 )/ (long)
> 65535 ) ; // ( ( voltage <<16) /2000000)  - 32000; //data  ;     //

Und was davon ist jetzt wirklich konstant?

>>>Digitalisierungsrauschen vom 16-Bit ADC.

Verwende einen 24 Bit ADC . Habe eine rauschfreie Auflösung 0.5 PPM 
erreicht.

>>>Und was davon ist jetzt wirklich konstant?

Hier der code, der funktioniert:
e =  (long) voltage - (((long long) data_roh * (long long ) 2000000 )/ 
(long long ) 65535 ) ;

>>>Damit kannst du das Ganze auch ohne 64-Bit-Arithmetik rechnen.

Diese Berechnung wird jede 250 ms ausgeführt. Aus Prozessorsicht eine 
Ewigkeit. Ich denke, eine 64-Bit Berechnung wird die Gesamt Performance 
vom System nicht sehr stark beeinträchtigen.

>>>Eine sehr gute Näherung für 2000000/65535 ist 26215/859

Danke für den guten Hinweis. Aber ein Argument spricht dagegen: Um die 
Wartung des Programms zu verbessern, ist die 
Lesbarkeit/Nachvollziehbarkeit nach z.B. 1 Jahr mit der ersten Methode 
besser.

Danke für eure Hilfe!
Gruß

DirkF schrieb:
> Danke für den guten Hinweis. Aber ein Argument spricht dagegen: Um die
> Wartung des Programms zu verbessern, ist die
> Lesbarkeit/Nachvollziehbarkeit nach z.B. 1 Jahr mit der ersten Methode
> besser.

Man kann alles übertreiben.

Irgendwie sollte es doch möglich sein, zwei Programmzeilen auch nach 
einem Jahr noch zu überblicken. Und zur Not gibt es die Möglichkeit, in 
solchen Fällen durch einen Kommentar Licht ins Dunkle zu bringen und so 
den Sinn solcher Formulierung zu erhellen.

Ich würde empfehlen in zukunft die <stdint.h> zu includieren und dann 
mit diesen Datentypen zu arbeiten. Dann gibt's kein "Ich dachte long 
sein 64bit" mehr, einfach int64_t.