Seltsamer Fehler mit Festkommaarithmetik und 7-Segment

Philipp schrieb:
> set_display_number(result*176/1024);

Ich vermute du wirst an der Stelle einen Overflow haben, d.h. result*176 
wird größer als es uint32_t zulässt. Übrigens würde ich mir an der 
Stelle die Division sparen und einfach

> result * 0.17185

rechnen.

oder x 11 / 64

@  Daniel H. (Firma: keine) (commander)

>> set_display_number(result*176/1024);

>Ich vermute du wirst an der Stelle einen Overflow haben, d.h. result*176
>wird größer als es uint32_t zulässt.

Kaum, denn result als ADC ergebniss ist max. 10 Bit, mal 176 (8 Bit 
macht) maximal 18 Bit. Ok, result ist wahrscheinlich 16 Bit, dann wird 
es ein Overflow. Also eher so.

1

set_display_number(result*176L/1024);

> Übrigens würde ich mir an der
>Stelle die Division sparen und einfach

>> result * 0.17185

>rechnen.

Dann wäre der Sinn von Festkommaarithmetik verfehlt.

Falk Brunner schrieb:
>> Übrigens würde ich mir an der
>>Stelle die Division sparen und einfach
>
>>> result * 0.17185
>
>>rechnen.
>
> Dann wäre der Sinn von Festkommaarithmetik verfehlt.

Jo, Vorsicht. Eine einzige float in so einer Berechnung zieht die math 
library rein und bläht den Code so richtig auf. Am besten immer ein Auge 
auf die Codegrösse beim Compilieren werfen, damit das nicht passiert.

Philipp schrieb:
> Die 176 kommen übrigends dadurch zustande, dass die Referenzspannung
> 1,1V beträgt und die zu messende Spannung per Spannungsteiler durch 16
> geteilt wird.

Das klingt übrigens so, als würdest du freiwillig eine Menge Auflösung 
verschenken. Absicht?

Wie sieht den der Funktionsprototyp von set_display_number() aus? Hat 
der auch uint32 oder nur uint16? Wenn uint16, dann versuche mal einen 
Type-Cast mit

1

set_display_number((uint16t)((result*11)/64));

Die Klammern habe ich gesetzt, damit der Compiler auch sicher nicht 
zuerst 11/16 rechnen will. Dabei kommt nämlich 1 raus...

tschuessle
Bernhard

Bernhard Spitzer schrieb:
> damit der Compiler auch sicher nicht zuerst 11/16 rechnen will.
Will er sicher nicht, denn da steht 64...
> zuerst 11/16 rechnen will. Dabei kommt nämlich 1 raus...
Bei mir kommt mit 11/16 nur 0 raus...


Man könnte da mal eine Zwischenvariable einführen, und die genauer 
anschauen. So würde ich das machen...

Philipp schrieb:
> Wenn z.B. 10.0 angezeigt werden müsste wird
> komischerweise 00.0 angezeigt und bei 12.0 wird 11.0 angezeigt.
Evtl. passt da auch einfach was mit dem Multiplexen nicht zusammen, und 
es wird die falsche Ziffer an der falschen Stelle angezeigt...

Bernhard Spitzer schrieb:
> Wie sieht den der Funktionsprototyp von set_display_number() aus? Hat
> der auch uint32 oder nur uint16? Wenn uint16, dann versuche mal einen
> Type-Cast mit
>

1

set_display_number((uint16t)((result*11)/64));

> Die Klammern habe ich gesetzt, damit der Compiler auch sicher nicht
> zuerst 11/16 rechnen will.

Das darf er sowieso nicht.
Neben Precedence gibt es ja auch noch die Assoziativität, die das klar 
regelt.

Philipp schrieb:
> Um diesen Codeausschnitt handelt es sich

Das ist ungefähr so, als würde von Dir jemand verlangen, ein Buch durchs 
Schlüsselloch zu lesen.

Code-Pfitzelchen bringen rein garnichts!
Da muß man ewig rumraten, wie alle Funktionen, Macros und Variablen 
deklariert sind und was sie vermutlich bedeuten könnten.

Zeig einen compilierbaren relevanten Code als Anhang.


Peter

Peter Dannegger schrieb:
> Philipp schrieb:
>> Um diesen Codeausschnitt handelt es sich
>
> Das ist ungefähr so, als würde von Dir jemand verlangen, ein Buch durchs
> Schlüsselloch zu lesen.

Den muss ich mir merken. Der ist gut.

Philipp schrieb:
> Ich reiche den vollständigen Code heute Abend noch nach.

Hallo Philipp,

wichtig ist auch die Information, welchen Compiler du nutzt und auf 
welchem Prozessor das Ganze läuft.

Grüße

Stefan

@  Philipp (Gast)

>Meine set number Methode zeigt aber alle Zahlen von 0-999 korrekt an(mit
>for getestet).

Wie? So hier?

1

      if(flag.multiplex==1)

2

      {

3

        flag.multiplex=0;

4

        //result = ADC;

5

        // test

6

        result = 1023;

7

        ADCSRA  |= (1<<ADSC);

8

9

        set_display_number(result*176/1024);

10

        set_dot(zehn);

11

      }

Was macht der Timer 1?


>    TIMSK1 = (1<<TOIE1);
>    TCCR1B = (1<<CS11);

Du gibst da einen Interrupt frei, für den ich die ISR nicht sehen kann. 
Nicht gut.


> Ich schätze es muss irgendwie mit dem ADC-Wert
> zusammenhängen, da dort manchmal schon völlig falsche
> Werte ausgespuckt werden.(?)

Das lässt sich ja überprüfen. Du hast eine Ausgabe zur Verfügung (wenn 
auch nur 3-stellig. Lässt du dir halt einfach immer die Hälfte vom ADC 
Wert anzeigen, dann passt der da rein. Dein Problem hängt ja nicht damit 
zusammen, dass der ADC Wert um +- 1 schwankt)

Wie ist die Aussenbeschaltung vom ADC?
ARef, AVcc?

Philipp schrieb:
> void set_display_number(uint16_t number)

Das dürfte die entscheidende Information sein.

set_display_number(result*176/1024) enthält also einen impliziten cast 
des Ausdrucks result*176/1024 auf uint16_t.

Wenn ich den Abschnitt "Conversions" (C89, identisch ISO/IEC 9899:1999) 
richtig verstehe, sollte dieser cast aber erst nach der Auswertung des 
rvalue greifen. result*176/1024 müsste also noch uint32_t sein.

Ok, schauen wir mal:
ADC 10 bit. *176 gibt 28 bit. /1024 ist ein Rechtshift um 10 bit, 
bleiben also 18 bit übrig. -> Das passt nicht in einen uint16_t.

Du hast aber nur 3 signifikante Ziffern, der Wert ist also eh zu weit 
aufgelöst. Ist der Umrechnungsfaktor wirklich passend?

Grüße

Stefan

Stefan Wagner schrieb:

> Ok, schauen wir mal:
> ADC 10 bit. *176 gibt 28 bit. /1024 ist ein Rechtshift um 10 bit,
> bleiben also 18 bit übrig. -> Das passt nicht in einen uint16_t.

Irgendwo musst du dich da verrechnet haben.
Das Ergebnis kann nur Werte im Bereich 0 bis 176 sein.

Ach ja, was mir noch auffiel:

Philipp schrieb:
> volatile uint8_t segmente[]={

Wenn ich das richtig sehe, ist das doch die Tabelle mit den Werten für 
die Ansteuerung der Segmente.

Warum dann die Deklaration als volatile? Diese Werte sind doch konstant 
und sollen es auch bleiben. Einer Optimierung durch den Compiler steht 
doch nicht im Wege, selbst wenn auch aus einer ISR auf das Array 
zugegriffen wird. (Die Deklaration const uint8_t segmente[] hielte ich 
für wesentlich sinnvoller.)

Grüße

Stefan

Philipp schrieb:

> Also wieder total komische Werte (von 199 -> 190 -> 101 -> 102 -> 200 ->
> 201).

Das sieht so aus, als ob die Segmenttabelle um 1 verschoben wäre.
eine angezeigte 9 ist eigentlich 8
                0 ist eigentlich 9
                1 ist eigentlich 0
usw.

> Und zwar nicht zufällig sondern diese Sprünge sind immer an der
> gleichen Stelle im Wertebereich. Ist meine 7-Segment Routine so OK

Ich hätt jetzt gesagt: ja

Schreibs mal so

1

void set_display_number(uint16_t number)

2

{

3

  if(number >= 999)

4

  {

5

    led_data[hundert] = segmente[9];

6

    led_data[zehn]    = segmente[9];

7

    led_data[eins]    = segmente[9];

8

  }

9

  else

10

  {

11

    led_data[eins] = segmente[ number % 10 ];

12

    number = number / 10;

13

14

    led_data[zehn] = segmente[ number % 10 ];

15

    number = number / 10;

16

17

    led_data[hundert] = segmente[ number ];

18

  }

19

}

Karl Heinz Buchegger schrieb:
> Irgendwo musst du dich da verrechnet haben.
> Das Ergebnis kann nur Werte im Bereich 0 bis 176 sein.

Ups. Ja. Und das hätte mir beim genauen Hinsehen auch auffallen müssen. 
(1023/1024 ist doch recht nahe an 1.) Ich war wohl doch schon zu müde.

Grüße

Stefan