Inkrement auslesen, Auflösung verringern

[Dezimator (Gast)]

Guten Tag,

ich lese einen inkrementellen Drehgeber mit 16 Bit aus, wobei ich 
allerdings die Auflösung um zwei Bit verringern will. Das Ergebnis 
benötige ich als Inkrement. Wichtig ist mir, dass der Fehler durch die 
Auflösungsverringerung nicht anwächst.

Würde ich einfach die Differenz zweier aufeinander Dekoderstände durch 
den Dezimierungsfaktor teilen, wüchse der Fehler schnell an. Also mache 
ich eine Division mit Restglied:

/* Inkrement aus Hardware-Decoder gewinnen bei verrringerter Aufloesung */
int getIncrement(void)
{
    const int8_t decimation = 4; // Zweierpotenz

    static uint16_t enc_n = 0;
    static int16_t rest = 0;
    
    uint16_t enc = (uint16_t) TIM_GetCounter(TIM3);
    int16_t denc = (int16_t) (enc - enc_n); // Vorzeichenrichtige Differenz
    enc_n = enc;
    
    int16_t dx = (denc+rest)/decimation;
    rest = (denc+rest)%decimation;

    return dx;
}

Das funktioniert wie erwartet.

Allerdings: Ist der Aufwand wirklich nötig, oder bin ich einem 
Denkfehler aufgesessen und es geht viel einfacher?

[Dezimator (Gast)]

Ich sehe gerade: Es geht. ich brauche den Divisionsrest ja nur von enc_n 
abziehen, und spare mir die zweite statische Variable.

[Falk B. (falk)]

Alles viel zu kompliziert.

https://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C

int8_t encode_read4( void )         // read four step encoders
{
  int8_t val;

  cli();
  val = enc_delta;
  enc_delta = val & 3;
  sei();
  return val >> 2;
}

[c-hater (Gast)]

Dezimator schrieb:

> Allerdings: Ist der Aufwand wirklich nötig, oder bin ich einem
> Denkfehler aufgesessen

Letzteres. Der Fehler wird sich immer im Bereich der weggeschnibbelten 
Bits bewegen, also im konkreten Fall eine Größe zwischen 0 und 3 
annehmen. Du muss dazu nur die zwei wegzuschnibbelnden Bits ÜBERALL 
ignorieren, das ist schon alles.

Am einfachsten machst du das, indem du einfach schon den Eingangswert 
durch den Dezimierungsfaktor teilst und in der Folge bloß noch mit den 
dezimierten Werten hantierst.

[Falk B. (falk)]

@c-hater (Gast)

>Letzteres. Der Fehler wird sich immer im Bereich der weggeschnibbelten
>Bits bewegen, also im konkreten Fall eine Größe zwischen 0 und 3
>annehmen. Du muss dazu nur die zwei wegzuschnibbelnden Bits ÜBERALL
>ignorieren, das ist schon alles.

Tja, und eben weil das eher unpraktisch ist, packt man das in eine 
Funktion.

>Am einfachsten machst du das, indem du einfach schon den Eingangswert
>durch den Dezimierungsfaktor teilst und in der Folge bloß noch mit den
>dezimierten Werten hantierst.

Er muss aber intern mit dem Rest weiter zählen, sonst kommt Mist raus.

[c-hater (Gast)]

Falk B. schrieb:

> Tja, und eben weil das eher unpraktisch ist, packt man das in eine
> Funktion.

Na klar, das war doch auch garnicht die Frage. Natürlich würde man das 
in eine Funktion packen. Überall schließt natürlich diese Funktion 
ein.

>>Am einfachsten machst du das, indem du einfach schon den Eingangswert
>>durch den Dezimierungsfaktor teilst und in der Folge bloß noch mit den
>>dezimierten Werten hantierst.
>

> Er muss aber intern mit dem Rest weiter zählen, sonst kommt Mist raus.

OMG, ich glaub' es nicht: Derselbe Denkfehler wie beim TO. Und das mit 
der angeblich SOOO GROOSSEN Programiererfahrung..

Nein, wenn man wie beschrieben vorgeht, also gleich an der Quelle die 
Bits wegschnibbelt und in der Folge nur noch mit der reduzierten 
Darstellung arbeiten (inbesondere auch beim Halter des letzten 
Zustands), kann man den Rest in den weggeschnibbelten Bits tatsächlich 
komplett ignorieren, der Fehler wird trotzdem niemals über den genannten 
Bereich anwachsen, weil er automagisch korrigiert wird, sobald er einen 
Wert von 4 (bzw. Vielfache davon) erreicht, dann gibt es nämlich in der 
reduzierten Interpretation einfach eine um 1 größere Änderung als 
nominell anstehen würde.

Das gilt übrigens für sogar für jeden Reduktionsfaktor, nicht nur für 
Zweierpotenzen. Man kann dann bloß nicht mehr so einfach die ignorierten 
Bits bennennen. Das interessiert aber auch niemanden wirklich...

[m.n. (Gast)]

Dezimator schrieb:
> Wichtig ist mir, dass der Fehler durch die
> Auflösungsverringerung nicht anwächst.

Willst Du Kernspeicher sparen?
Verringere die Auflösung erst ganz zum Schluß, nachdem alle Berechnungen 
(ggf. Skalierung) mit dem ursprünglichen Wert durchgeführt wurden.

[Dezimator (Gast)]

c-hater schrieb:
> Am einfachsten machst du das, indem du einfach schon den Eingangswert
> durch den Dezimierungsfaktor teilst und in der Folge bloß noch mit den
> dezimierten Werten hantierst.

Das wird nicht klappen. Dann stimmt der Überlauf der unsigned-Variablen 
nicht mehr.


Falks Lösung dürfte klappen, wenn man val static macht und statt & 3 
&(~3) macht.