Falsche Berechnungen mit ATtiny26

[Sandro L. (sandro_l)]

Hallo,
Ich habe folgendes Programm auf einen ATtiny26 geflasht:

#include <avr/io.h>

#include <avr/interrupt.h>
#include <avr/sleep.h>

volatile uint16_t counter;
volatile uint32_t adcValue;

void showNumber(uint16_t value) {
    // Code zur Anzeige auf 7-Segment-Anzeigen ...
    // Verwendet Timer1 (zählt auch die "counter" Variable hoch)
}

void startAnalogConversion() {
    // Prepare ADC noise cancelling mode
    set_sleep_mode(SLEEP_MODE_ADC);
    sleep_mode();
    // Loop if the interrupt that woke the cpu was something other than the ADC finishing the reading
    while((ADCSR & (1<<ADSC)) != 0) {
        sleep_mode();
    }
    // Vordefinierter Wert zu Testzwecken
    adcValue = 200;
    
    showNumber(adcValue);             // funktioniert:       Zeigt 200 an.
    showNumber((adcValue * 50) / 55); // funktioniert:       Zeigt 181 an.
    showNumber((adcValue * 96) / 100);// funktioniert nicht: Zeigt 102 an.
}

void setup() {
    // Analog-Digital-Converter (ADC)
    ADMUX = (1<<REFS1) | (1<<REFS0); // select internal reference source (2.56V) and input channel ADC0
    ADCSR = (1<<ADEN)  | (1<<ADIE) | (1<<ADPS2);   // enables ADC with prescaler 16 and activates interrupt

    counter = 0;

    sei();

    startAnalogConversion();
}

int main(void)
{
    setup();
    
    for(;;) {
        if (counter >= 500) {
            counter = 0;
            startAnalogConversion();
        }
    }
    return 0;   /* never reached */
}

ISR(ADC_vect)
{
    adcValue = ADC;
}

In der Funktion "startAnalogConversion" möchte ich den Wert von 
"adcValue" * 0.96 rechnen. Diese Berechnung ( (adcValue * 96) / 100 ) 
funktioniert jedoch nicht so wie erwartet. Wenn adcValue den Wert 200 
hat, sollte das Resultat 192 sein. Es kommt jedoch immer 102 als 
Ergebnis raus. Im Anhang habe ich das verwendete Makefile angehängt.

Was könnte der Grund sein, dass diese Berechnung nicht funktioniert?

Beste Grüsse,
Sandro

[Nobody (Gast)]

Der Fehler stecht da, wo du ihn nie vermuten würdest!
Darum hast du den Teil ja auch abgeschnitten.

Ein Bug in: showNumber();
ohne Gewähr

[Timmo H. (masterfx)]

Und wie sieht der Inhalt von showNumber aus?

[Johann L. (gjlayde)]

Möglicherweise überschreibt die ISR den adcValue von 200.

[(prx) A. K. (prx)]

Bei Soll=192 und Ist=102 käme evtl. auch ein Fehler in der 7-Segment 
Ausgabe in Frage. Was kommt denn bei showNumber(192) raus?

[Nobody (Gast)]

Das Auslesen von adcValue muss sowieso ATOMIC erfolgen.
Aber das Problem würde dann nur sporadisch auftreten, wäre also eher 
schwer reproduzierbar.

[Sandro L. (sandro_l)]

A. K. schrieb:
> Bei Soll=192 und Ist=102 käme evtl. auch ein Fehler in der 7-Segment
> Ausgabe in Frage. Was kommt denn bei showNumber(192) raus?

bei showNumber(192) wird auch 102 ausgegeben. Muss wohl doch an der 
Ansteuerung der Anzeige liegen..

In showNumber extrahiere ich die einzelnen Ziffern, welche danach per 
Timer ISR an die 7-Segment-Anzeigen ausgegeben werden:

void showNumber(uint16_t value) {
    digits[0] = value / 100;
    value -= digits[0] * 100;
    digits[1] = value / 10;
    digits[2] = value - (digits[1] * 10);
}

Ich habe den Fehler gefunden. Da habe ich doch glatt etwas ganz banales 
übersehen. Ich habe in der Timer ISR geprüft, ob die Ziffer < 9 ist 
(müsste Ziffer < 10 sein). Falls nicht, wird "0" angezeigt.

Besten Dank für die vielen Tipps.

[Sandro L. (sandro_l)]

Nobody schrieb:
> Das Auslesen von adcValue muss sowieso ATOMIC erfolgen.
> Aber das Problem würde dann nur sporadisch auftreten, wäre also eher
> schwer reproduzierbar.

Um adcValue korrekt auszulesen, muss ich folgende Schritte einbauen:
1. Die globalen Interrupts deaktivieren
2. adcValue auslesen
3. Die globalen Interrupts wieder aktivieren

Habe ich das so richtig verstanden?

[Nobody (Gast)]

Ja!
Da gibts fertige Macros für...

[Nobody (Gast)]

http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html

[Karl M. (Gast)]

Hallo,
hast Du hier an eine Cast auf uin32_t gedacht ?
(adcValue * 96)
sonst gibt einen 16Bit Überlauf.

[Karl M. (Gast)]

Ach ja,

es ist natürlich so, dass der ATtiny26 mit dem avr gcc Paket richtig 
rechnet !

Was bleibt, ist dann der Mensch.

[Peter D. (peda)]

Karl M. schrieb:
> es ist natürlich so, dass der ATtiny26 mit dem avr gcc Paket richtig
> rechnet !

Der ATtiny26 hat in der Tat einen Hardwarebug, der z.B. ltoa() 
fehlerhaft ausgeben läßt.
Man sollte besser den ATtiny261 nehmen.

[Ingo L. (corrtexx)]

Karl M. schrieb:
> hast Du hier an eine Cast auf uin32_t gedacht ?
Aber nicht wenn adcValue vom Typ uint32_t ist.
Versuch mal:

void showNumber(uint16_t value) {
    digits[0] = value / 100;
    digits[1] = (value / 10) % 10;
    digits[2] = value % 10;
}