double in IAR für AVR

Andreas Ruetten schrieb:

Nein. Die Genauigkeit der Umrechnung kann noch so hoch sein, das Ergebnis kann niemals die Genauigkeit der Ursprungswerte überbieten. Bei den digitalisierten Werten ist es halt doch so, daß "ganz viel 1 schon ein bisschen 2 ist". Wenn also Deine vollen 12 bit z.B. den Temperaturbereich von 0 bis 1000°C darstellen, so ist jeder Wert mit einem Meßfehler von rund 1/2°C behaftet. Eine Genauigkeit der Berechnung auf 5 signifikante Stellen ist also durchaus ausreichend.

Die Umrechnung kann ja problemlos vorher ausgerechnet werden und in Tabellen abgelegt werden. ggf. eben auch, bei variablen Umrechnungskoeffizienten wegen unterschiedlichen Meßbereichen, in Form von Zwischenwerten.

Daß sich Meßwerte zur Laufzeit ändern, sollte selbstverständlich sein. Meinst Du evtl. Werte = Umrechnungskoeffizienten? Das ergibt sich aber aus dem Programmbeispiel überhaupt nicht und wurde auch an dieser Stelle erstmals erwähnt.

Bernd

Reply to
Bernd Laengerich
Loading thread data ...

Am 27.03.2010 20:44, schrieb Bernd Laengerich:

Ist schon klar, es ging darum das es eben nicht unterboten werden sollte. Und genau das tut es aber im Moment beim Codevision und den Floatberechnungen. Weil da eben double ebenfals wie float nur 32Bit sind.

Es ist ja nur ein verkürzter Auszug, und ich wollte ja auch keine Diskussion über das für und wieder von interpolierten Tabellen usw. Sondern ich wollte nur Wissen warum der IAR Compiler aus der Berechnung keinen tauglichen Wert rausbringt und verkackt während es beim Codevision klaglos tut.

Andreas

Reply to
Andreas Ruetten

"nur" 32 Bit? Berechnest Du große Determinanten oder sowas? Alles, was der arme Atmel in endlicher Zeit in double berechnen kann, sollte mit 24 Bit Mantisse locker abgedeckt sein. Was hängt denn da wirklich dran? Der PT100 kann nicht der Grund für diesen Aufwand sein.

Ich tippe auf Demoversion.

--
Gruß, Raimund
Mein Pfotoalbum 
Mail ohne Anhang an  wird gelesen. Im Impressum der Homepage
findet sich immer eine länger gültige Adresse.
Reply to
Raimund Nisius

Ich hab mir die Tabelle mal für ein Poti aus Referenz 150Ohm und PT100 berechnet. Es gibt 3043 Temperaturen zwischen -246.82°C und 1002.42°C.

diese Temperaturen in 1/100C als 17 Bitwerte gespeichert kosten 6469 Byte.

Die Differenzen zwischen den Tabellenwerten gehen von 8 bis 201. Die kosten mit 8 Bit 3043 Byte und die Temperatur bei ADC = 0.

Die Differenzen der Differenzen nehmen nur 4 Werte (-1,0,1,2) an, die man mit 2 Bit speichern kann. Das wären dann 761 Byte sowie die Temperatur bei ADC = 0 und die erste Differenz.

Schafft man das mit Huffmann? Der Huffmann-Algorithmus selbst ist sehr groß. Die Auswertung der "2. Ableitung" besteht nur aus einer kleinen Schleife. Unter Verwendung des letzten Messwertes auch sehr schnell, da man nur wenige ADC-Schritte weiter berechnen muß.

Wie wärs mit nem Contest um die platzsparendste ADC-Auswertung?

--
Gruß, Raimund
Mein Pfotoalbum 
Mail ohne Anhang an  wird gelesen. Im Impressum der Homepage
findet sich immer eine länger gültige Adresse.
Reply to
Raimund Nisius

Hallo Andreas, hast du im Compiler Manual mal nachgelesen was man für double tun muss.

"By default double is treated as float."

Ansonsten braucht man extra einen Compiler-switch.

--64bit_doubles

Hast du auch math.h eingebunden?

Gruß Helmut

Reply to
Helmut Sennewald

Am 28.03.2010 12:23, schrieb Helmut Sennewald:

Ja

Ja, der ist aktiviert.

ja

Andreas

Reply to
Andreas Ruetten

Ja, weil die einen "die shrink" vorgenommen haben. Die haben jetzt einfach ein A hintendran und gut ist ... Also kein Problem. Problematisch sind im Moment eher die Lieferzeiten...

Andreas

Reply to
Andreas Ruetten

Mach Dir lieber Gedanken um "Note: Not recommended for new designs" sagt immerhin der Hersteller...

formatting link

--
Gruß, Raimund
Mein Pfotoalbum 
Mail ohne Anhang an  wird gelesen. Im Impressum der Homepage
findet sich immer eine länger gültige Adresse.
Reply to
Raimund Nisius

Am 26.03.2010 19:23, schrieb Klaus Butzmann:

LTZ1000 ist schon ein echt feines Teil wenn man mit 24 oder gar noch mehr Bits arbeitet.

Weiß zufällig jemand wo man den in 10er Stückzahlen ( und zu vernünftigen Preisen) bekommen kann?

Gruß

Thorsten

Reply to
Thorsten Just

Andreas Ruetten schrieb:

Hallo,

warum schreibst Du da nicht einfach:

x2 = -1.1604E-4;

entsprechend auch bei x1, x3, x4 und T.

Gibt es da irgendeinen vernünftigen Grund dafür die Konstanten so fürchterlich umständlich zu definieren?

Bye

Reply to
Uwe Hercksen

Am 29.03.2010 11:25, schrieb Uwe Hercksen:

Da der Compiler keine tauglichen Berechnungen lieferte, habe ich herumexperimentiert. Voher war z.Bsp (double)100 auch variabel.

Aber das funktionierte auch nicht mit dem Compiler.

Andreas

Reply to
Andreas Ruetten

Am 29.03.2010 08:40, schrieb Thorsten Just:

Ebay Item 260474645765, Versand aus Hong Kong absolut problemlos, bei zehn Stück würde ich unter snipped-for-privacy@hotmail.com direkt anfragen, sehr netter Kontakt. Sieben Satz der Exotenwiderstände 13k, 120R und 70K hätte ich noch übrig, die Standardwerte Vishay S102C gibts beim Bürklin einzeln.

Butzo

Reply to
Klaus Butzmann

Uwe Hercksen schrieb:

Weil es völlig egal ist?

-- cheers, J"org .-.-. --... ...-- -.. . DL8DTL

formatting link
NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)

Reply to
Joerg Wunsch

Am 29.03.2010 23:19, schrieb Klaus Butzmann:

Hm, die sind angeblich schon mal eingelötet gewesen. Da wäre ich grundsätzlich ja skeptisch was die Qualität angeht. Wie sind denn da die Erfahrungen mit soetwas?

Gruß

Thorsten

Reply to
Thorsten Just

Am 30.03.2010 08:56, schrieb Thorsten Just:

Meine haben den Datecode 0135 und 13mm lange Anschlussbeine, wenn entlötet dann hats jemand sehr sorgfältig gemacht.

Butzo

Reply to
Klaus Butzmann

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.