AVR oder TTL f. Laengenanzeige?

[Rolf Bredemeier]

Hallo Daniel!

Daniel Schramm wrote:

Im Moment scheint es Mode zu sein, erst das Werkzeug festzulegen und
dann die Aufgabe zu definieren, satt das Werkzeug als letztes passend
zur Aufgabe zu wählen.
Nur ne generelle Feststellung, der Inhalt der Nachricht ist ja nicht
festgelegt, aber bei der Überschrift hatte ich schon wieder etwas
anderes erwartet....

Ich möchte gerne Fehler beim Posten vermeiden, und aus gemachten
zumindest lernen.

Nur weiss ich nicht, was falsch an meiner Frage war.

Die Aufgabe war doch klar: Impulse zählen zur Länegnmessung.
Und die mir zugänglichen Werkzeuge waren genannt.

Was also war falsch?

Ausser, das ich mir das Posting hätte sparen können, wenn
ich gleich gerechnet und nicht gefühlt hätte. Siehe weiter unten
im Thread.

Viele Grüße, Rolf

 

[Rolf Bredemeier]

Hallo David!

Ich nehme an, dieser inkrementalgeber funktioniert nacht dem
Quadratur-Encoder prinzip oder? 2 Phasen, 90° verschoben? Da hab ich
nämlich auch schon was programmiert und hatte wirklich keine Probleme,
war auch Interrupt gesteuert. Meiner Meinung nach müsste es mit einem
Atmega8 und 16MHz taktfrequenz kein problem sein, auch jenseits von
20KHz zu samplen. Also ich persönlich würde es Softwaremässig
versuchen. Mit TTL-Bausteinen wird es da schon viel komplizierter, als
mit Software...

Hast recht, geht also in Software.

könnte mich sonst auch noch umschauen wegen dem algorithmus.

Ganz lieb von Dir, steht aber in der FAQ.

Vielen Dank und viele Grüße, Rolf

 

[Rolf Bredemeier]

Hi Christoph!

Christoph Drube wrote:

Ich hab Digitalanzeigen entwickelt, die (auch Atmel-basierend)
bei einem Encodereingang locker 100 kHz verkraften, bei vier Achsen
gleichzeitig immer noch über 60 kHz.
Und gleichzeitig macht das Teil noch die Umrechnung beliebiger
Auflösungen, lässt sich über RS-232 auslesen und programmieren und
steuert pro Achse acht 7-Seg-LEDs flimmerfrei an, dazu noch diverse
andere Goodies (Displayhelligkeit lässt sich per PWM einstellen usw.)

Alles mit *einem* Controller, 16 MHz und 8kByte Speicher.

Hut ab!

Zugegeben, die Programmierung war nicht ganz trivial. Aber 20 kHz
solltest Du locker hinkriegen.
Also nur Mut!

Habe ich ich wieder. Die eigentliche Interruptroutine ist jetzt 102 Zyklen
lang und fast fertig. Geht wirklich locker!

Viele Grüße aus der Vulkaneifel,

Das Gleiche aus dem sonnigen Petershagen! ;-)

Rolf

 

[Daniel Schramm]

Rolf Bredemeier wrote:

Hallo Daniel!

Daniel Schramm wrote:
Im Moment scheint es Mode zu sein, erst das Werkzeug festzulegen und
dann die Aufgabe zu definieren, satt das Werkzeug als letztes passend
zur Aufgabe zu wählen.
Nur ne generelle Feststellung, der Inhalt der Nachricht ist ja nicht
festgelegt, aber bei der Überschrift hatte ich schon wieder etwas
anderes erwartet....

Ich möchte gerne Fehler beim Posten vermeiden, und aus gemachten
zumindest lernen.

Nur weiss ich nicht, was falsch an meiner Frage war.

An der Frage war nichts Falsch, die war gut formuliert.
Das Problem gut geschildert, die Aufgabe klar dargestellt, ...

Nur das Subject suggerierte, dass Du auf eine bestimmte Microcontroller
Plattform vorab festgelegt bist.
Viele Fragen, nicht nur in dieser Newsgroup (meines empfindens momentan
überall in Deutschland), schreiben den Lösungsweg oder ein Werkzeug (Hard-
oder Software) vor und dann soll man damit die Aufgabe lösen, obwohl es bei
weitem billigere und effizientere Wege gäbe.
Das stösst mir immer etwas auf.

(Beispiele:
- Festlegung auf ein Betriebssytem, ohne Rücksicht auf den Einsatzzweck,
siehe Schaltungs-Software-Thread.
- Windows in harten Echtzeitumgebungen
- Windows CE Touchscreen Bedienteile, die schön bunt, aber fast unbedienbar
langsam sind, Microcontroller und einzeiliges Textdisplay waere
Anwenderfreundlicher.
- die Liste liesse sich endlos fortsetzen)

Einige schreiben zum Teil sogar nur das Werkzeug vor und vergessen die
Beschriebung der Aufgabe.

Aber wie ich schon geschrieben hatte, nach dem Subject hat mich der Inhalt
positiv überrascht.

Gute Nacht

Daniel

--
.~. Daniel Schramm Phone: +49 231 6108112 Mail:daniel.schramm@gmx.de
/V\ Bruehlweg 36 Mobile:+49 178 8839848 ICQ: 35816985
// \\ 44379 Dortmund Fax: +49 231 96989961 WWW: pinguin.sauerland.de
/( )\ Germany
^`~'^

 

[Georg Seegerer]

Nur das Subject suggerierte, dass Du auf eine bestimmte Microcontroller
Plattform vorab festgelegt bist.

Da sich die Frage eher nach Hobbyprojekt als nach einer Großserie
anhörte kann das durchaus Sinn machen. Als Hobbyist arbeitet man sich
nicht unbedingt in eine neue Mikrokontroller-Umgebung ein nur weil der
PIC mit dem Quadratur-Eingang 1 Euro billiger ist als der entsprechende
AVR.
Man nimmt die Teile und Methoden mit denen man sich auskennt und schaut
wie man damit hinkommt, auch wenns etwas umständlicher wird. Schon wegen
der Zeitersparnis. Im schlimmsten Fall entscheidet der Inhalt der
Bastelkiste über die Bauteilauswahl (in meinem Fall ein Mega8 zum
Dekodieren einer IR-Fernsteuerung -> hoffnungslos überdimensioniert,
aber extra einen kleineren bestellen? Ist ja schon wegen der Versand-
kosten ein Minusgeschäft.)

Georg

--
Die Reply-To Adresse ist reply-fähig ;-)

 

On Wed, 14 Sep 2005 18:43:32 +0200, Heinz Liebhart wrote:

On Wed, 14 Sep 2005 17:48:27 +0200, "MaWin" <me@private.net> wrote:

"Peter Muthesius" <newsname@gmx.de> schrieb im Newsbeitrag
news:43284374$0$18641$14726298@news.sunsite.dk...
Hallo,

Weil man das genau so ganz ganz bestimmt nie machen sollte ?

*grmpf*erwischt*schäm*

Aber einen muss ich noch drauf setzten, auch wenn ich meinen
Denkfehler einsehe. Mit _einem_ Int-Pin wirds nix, klar.

Aber wenn _zwei_ Pins Int-fähig sind kann ich doch ganz leicht die
State-Machine auch dort implementieren. Muss mir nur die Zustände des
jeweils anderen Pins mit merken....

Und WENN Prellen kommt dann halt einfach ignorieren, weils ja noch der
alte Zustand ist. Schnelles prellen müsste sowieso wegzubekommen sein,
weil ja der selbe Interrupt nicht sofort wieder auslöst...

Oder mach ich da schon wieder einen Denkfehler?

Heinz

 

[Peter Muthesius]

Hallo,

Aber wenn _zwei_ Pins Int-fähig sind ...
Wichtig ist halt, dass man _beide_ Flanken des Signals auswertet, nicht

dass man zwei Int.-Pins hat.

Aber: Angenommen, das Teil stehe auf der Kippe. Es gäbe einen kurzen
Impuls ab, überlegt es sich aber anders. Dann würde mit Impulsbeginn ein
Int. angefordert werden, während das Ende verschluckt würde.

Je nach Architektur, sicher jedoch bei der vier Pin-Lösung, würde die
zweite Anforderung warten, bis die erste abgearbeitet ist.

Wenn man zwei Pins hat, die jeweils auf beide Flanken reagieren (oder
mit vier Pins und passender Programmierung/Beschaltung, wenn das nicht
geht), kann man die Auflösung verdoppeln.

Aber selbst dann kann, wenn das Ding auf Kippe steht, die Int.-Last sehr
hoch werden.

Ich habe es mal so implementiert auf einer C166-Architektur. Da kann man
einen Pin auf beiden Flanken /einen/ Int. anfordern lassen. Der
beschriebene Fall ("Je nach Architektur...") macht keine Probleme, da
die Interrupts nicht wirklich flankengetriggert angefordert werden,
sondern eine State-Machine in der Interrupt-Logik ihrerseits die
Zustände der Pins alle 16 (?) Systemtakte abfragt.

Ansonsten war es ein optischer Encoder an Schmitt-Trigger-Eingängen, der
prellt halt nicht. Problematisch war nur die Abfrage des jeweils
anderen, keinen Int. anfordernden Signals, da dieses erst in der
Routine, also nicht zum Zeitpunkt der anfordernden Flanke erfolgt.
Allerdings war der Encoder "nur" für Benutzer-Eingaben zuständig, da ist
ein gewisser Schlupf normalerweise tolerierbar. Im Übrigen habe ich auch
bei extremeren Bewegungen keinen Schlupf gefühlt (d. h. nicht, dass es
nachgemessen hätte).

HTH - Peter

--
Für Privat-Email bitte Betreff mit "Usenet-Reh" beginnen lassen.
--
"Ein Mokka-Trüffel-Parfait mit einem Zitronencreme-Bällchen."

 

[Peter Muthesius]

Nachtrag:

Problem meiner Implementierung war, dass bei sehr schnellen Bewegungen
der Zähler aus dem Tritt kommen kann, was bei der Anwendung nicht
praxisrelevant war.

Wertet man jedoch nur eine Flanke aus, kann man auch durch beliebig
langsames Hin- und Herdrehen an der richtigen Stelle den Zähler immer
weiter zählen lassen

Guten Abend

--
Für Privat-Email bitte Betreff mit "Usenet-Reh" beginnen lassen.
--
"Ein Mokka-Trüffel-Parfait mit einem Zitronencreme-Bällchen."

 

[Michael Schöberl]

Aber wenn _zwei_ Pins Int-fähig sind kann ich doch ganz leicht die
State-Machine auch dort implementieren. Muss mir nur die Zustände des
jeweils anderen Pins mit merken....

ich könnte mir vorstellen, dass das auch geht ... wenn man für beide
Pins und beide Flanken einen Interrupt erzeugen kann


Vorteil: die mittlere Systemlast sinkt deutlich

- Bei Ruhe: gar keine Rechenleistung nötig
- bei voller Drehgeschwindigkeit hat man etwa die Last wie
beim Einsatz des Timer-interrupts
- wenns prellt bekommt man im worst case kurzfristig 100% Last


Die Auswertung bleibt aber trotzdem zustandsgesteuert!



bye,
Michael

 

[Falk Brunner]

"Peter Muthesius" <newsname@gmx.de> schrieb im Newsbeitrag
news:4329d694$0$18640$14726298@news.sunsite.dk...

Hallo,

Aber wenn _zwei_ Pins Int-fähig sind ...
Wichtig ist halt, dass man _beide_ Flanken des Signals auswertet, nicht
dass man zwei Int.-Pins hat.

Aber: Angenommen, das Teil stehe auf der Kippe. Es gäbe einen kurzen
Impuls ab, überlegt es sich aber anders. Dann würde mit Impulsbeginn ein
Int. angefordert werden, während das Ende verschluckt würde.
Je nach Architektur, sicher jedoch bei der vier Pin-Lösung, würde die
zweite Anforderung warten, bis die erste abgearbeitet ist.

Wenn man zwei Pins hat, die jeweils auf beide Flanken reagieren (oder
mit vier Pins und passender Programmierung/Beschaltung, wenn das nicht
geht), kann man die Auflösung verdoppeln.

Aber selbst dann kann, wenn das Ding auf Kippe steht, die Int.-Last sehr
hoch werden.

Ich habe es mal so implementiert auf einer C166-Architektur. Da kann man
einen Pin auf beiden Flanken /einen/ Int. anfordern lassen. Der
beschriebene Fall ("Je nach Architektur...") macht keine Probleme, da
die Interrupts nicht wirklich flankengetriggert angefordert werden,
sondern eine State-Machine in der Interrupt-Logik ihrerseits die
Zustände der Pins alle 16 (?) Systemtakte abfragt.

Ohh je. Was eine handoll TTL ICs spielend bis in den MHz Bereich machen kann
wird hier mit biegen und brechen in Software gestopft.
Muss (und will) ich nicht verstehen.

Schmitt-Trigger-Eingängen, der

prellt halt nicht. Problematisch war nur die Abfrage des jeweils

Falsch. Der kann auch prellen. Es sei denn man hat einen richtig
dimensionierten RC-Filter davor.

kt der anfordernden Flanke erfolgt.

Allerdings war der Encoder "nur" für Benutzer-Eingaben zuständig, da ist
ein gewisser Schlupf normalerweise tolerierbar. Im Übrigen habe ich auch
bei extremeren Bewegungen keinen Schlupf gefühlt (d. h. nicht, dass es
nachgemessen hätte).

Aha, sowas wie gefühlte Temperaturen. Naja.

MfG
Falk

P.S. Warum wollen alle Lete das Fahrad neu erfinden und bauen dabei 4eckige
Räder dran??

P.P.S. Um auf die Ursprungsfrage zu antworten.

a) "hippe" Lösung. kleiner CPLD mit 32 Macrozellen, z.B. Coolrunner oder
XC9500XL
b) "classic" eine Handvoll TTL Gatter, da kann man sein Talent für
Logikoptimierung (Karnaught & Co) beweisen

 

[Peter Muthesius]

Hallo,

Schmitt-Trigger-Eingängen, der prellt halt nicht.
Falsch. Der kann auch prellen. Es sei denn man hat einen richtig
dimensionierten RC-Filter davor.
Bitte erläutere das näher.

a) "hippe" Lösung.
b) "classic"
Ich verstehe nicht, warum man nicht eine SW-Lösung machen soll, wenn man

keine Megahertze braucht.

Gute Nacht - Peter

--
Für Privat-Email bitte Betreff mit "Usenet-Reh" beginnen lassen.
--
"Ein Mokka-Trüffel-Parfait mit einem Zitronencreme-Bällchen."

 

[Joerg Wunsch]

"Falk Brunner" <Falk.Brunner@gmx.de> schrieb:

b) "classic" eine Handvoll TTL Gatter, da kann man sein Talent für
Logikoptimierung (Karnaught & Co) beweisen

Sicher dafür eine schöne Übung, ansonsten x-facher Leistungs- und
Platzverbrauch gegenüber dem Controller.

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

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

 

[Falk Brunner]

"Peter Muthesius" <newsname@gmx.de> schrieb im Newsbeitrag
news:4329ea5f$0$18646$14726298@news.sunsite.dk...

Hallo,

Schmitt-Trigger-Eingängen, der prellt halt nicht.
Falsch. Der kann auch prellen. Es sei denn man hat einen richtig
dimensionierten RC-Filter davor.
Bitte erläutere das näher.

Nun, was ist denn Prellen? Hier beim Inkrementalgeber bedeutet das, dass ein
Kanal sehr schnell seinen Zustand wechselt, wesentlich schneller als bei
maximaler Drehzahl (Pulszahl). Auf diese kurzen Impulse reagiert natürlich
auch der Schmitt-trigger (wieso auch nicht?). Erst ein RC-Filter vor dem
Schmitt-trigger filtert die sehr kurzen Pulse weg.

a) "hippe" Lösung.
b) "classic"
Ich verstehe nicht, warum man nicht eine SW-Lösung machen soll, wenn man
keine Megahertze braucht.

Nun ja, der OP sprach von 20 kHz Pulsfrequenz. Macht 50us. Bei 10 MHz
CPU-takt sind das gerade mal 500 Takte. Nimmt man dann noch einen Faktor 2-4
für die Überabtastung dazu sinds nur noch 125 Takte. Für die reine
Quadraturdekodierung reichts vielleicht. aber er will ja noch die Anzeige
machen, das wird dann schon kniffelig.

Machbar (mit ner gehörigen Portion KnowHow oder oversized CPU) aber nicht
unbedingt meine Empfehlung. Ausserdem hatten wir ja vor kurzem das Problem
dass ein Controller mal so fix nebenher inen Inkrementalgeber auswerten
sollte. Schön schnell, 100%OK aber ohne Rechenpower. Naja.

MfG
Falk

 

[Falk Brunner]

"Joerg Wunsch" <j@uriah.heep.sax.de> schrieb im Newsbeitrag
news:dgdjt4$vh2$1@uriah.heep.sax.de...

b) "classic" eine Handvoll TTL Gatter, da kann man sein Talent für
Logikoptimierung (Karnaught & Co) beweisen

Sicher dafür eine schöne Übung, ansonsten x-facher Leistungs- und
Platzverbrauch gegenüber dem Controller.

Schon klar, deshalb auch "classic". Und wer keine Erfahrung mit Controllern
hat, kann das vielleicht eher hinkriegen.

MfG
Falk

 

[Henning Paul]

Peter Muthesius schrieb:

Wenn man zwei Pins hat, die jeweils auf beide Flanken reagieren (oder
mit vier Pins und passender Programmierung/Beschaltung, wenn das nicht
geht), kann man die Auflösung verdoppeln.

Die neuen ATMegas haben doch einen Pin-Change-Interrupt: Eine beliebige
Flanke an bis zu 8 maskierbaren I/O-Pins löst einen Interrupt aus. Ist doch
ideal für diese Anwendung.

Gruß
Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613

 

[Andreas Donner]

"Falk Brunner" <Falk.Brunner@gmx.de> schrieb:

Nun ja, der OP sprach von 20 kHz Pulsfrequenz. Macht 50us. Bei 10 MHz
CPU-takt sind das gerade mal 500 Takte. Nimmt man dann noch einen
Faktor 2-4
für die Überabtastung dazu sinds nur noch 125 Takte. Für die reine
Quadraturdekodierung reichts vielleicht. aber er will ja noch die
Anzeige
machen, das wird dann schon kniffelig.

Auch auf die Gefahr hin, etwas zuviel zu versprechen: Nach meiner
Einschätzung reicht für den Zweck Impulszählung und multigeplexte
Anzeige auch ein tiny2313. Auch eine Übersprungsdetektion zur Warnung
vor "Verzählern" dürfte noch problemlos machbar sein.

Die Lösung besteht dann im Wesentlichen aus einem 20-Pinner, einem
Quarz, fünf 7-Segment-Ziffern nebst Widerständen und ein paar KerKos.
Schätze mal ein, wieviele TTL-Käfer kann man verbauen (und wie gross,
und kostet wieviel), um denselben Zweck zu erreichen?

--
Es gibt keine Neue Rechtschreibung. Es gibt eine Rechtschreibung und
eine neue Schreibweise. Ausserdem hätte ich lieber eine
Mathematikreform, dann wäre das Rechnen nicht so schwer.

 

[Falk Brunner]

"Andreas Donner" <AnDon@gmx.de> schrieb im Newsbeitrag
news:dgf27m$1o6g$1@ulysses.news.tiscali.de...

"Falk Brunner" <Falk.Brunner@gmx.de> schrieb:

Nun ja, der OP sprach von 20 kHz Pulsfrequenz. Macht 50us. Bei 10 MHz
CPU-takt sind das gerade mal 500 Takte. Nimmt man dann noch einen
Faktor 2-4
für die Überabtastung dazu sinds nur noch 125 Takte. Für die reine
Quadraturdekodierung reichts vielleicht. aber er will ja noch die
Anzeige
machen, das wird dann schon kniffelig.

Auch auf die Gefahr hin, etwas zuviel zu versprechen: Nach meiner
Einschätzung reicht für den Zweck Impulszählung und multigeplexte
Anzeige auch ein tiny2313. Auch eine Übersprungsdetektion zur Warnung
vor "Verzählern" dürfte noch problemlos machbar sein.

Einen 16 Bit Zählerstand auf ein paar 7Segmentanzeigen zu MUXen ist kein
Akt, da langweilt sich der Controller zu Tode.
Aber mit 80 KHz die Quadraturimpulse zu sampeln UND nebenbei die Anzeige
MUXEN wird schon ne kleine bis mittlere Herausforderung. Nicht vergessen, du
musst noch von binär in dezimal umrechnen, oder gleich in BCD zählen, was
auch mit einem gewissen (Zeit)aufwand verbunden ist.

Die Lösung besteht dann im Wesentlichen aus einem 20-Pinner, einem
Quarz, fünf 7-Segment-Ziffern nebst Widerständen und ein paar KerKos.

Hardware soweit klar. Der Knackpunkt ist die Software. Mach mal, wir werden
dann mal sehen.

Schätze mal ein, wieviele TTL-Käfer kann man verbauen (und wie gross,
und kostet wieviel), um denselben Zweck zu erreichen?

Ich hab nie behauptet, dass das TTL-Grab kleiner und billiger ist. Es ist
jedoch für die Microcontroller-unerfahrenen (ja gibts denn sowas heute noch
? ;-) einfacher aufzubauen (Idee vom OP, Einfach Dekoder +
Vorwärts/Rückwärtszähler + Reset).

Ich würde prinzipiell auch gern beweisen, dass es mit nem kleinen 20pin AVR
geht. Records are made to be broken!

Also, wer macht mit?

MfG
Falk

 

[Peter Muthesius]

Hallo,

Nun, was ist denn Prellen? Hier beim Inkrementalgeber bedeutet das ...
Also, Du meinst nicht das Prellen mechanischer Kontakte, welches

natürlich auch bei mechanischen Kontakten in Encodern auftritt. (Zumal
ich ja von optischen Encodern sprach.)

... dass ein Kanal sehr schnell seinen Zustand wechselt, wesentlich
schneller als bei maximaler Drehzahl (Pulszahl).
Warum sollte ein Kanal schnell seinen Zustand wechseln? Wenn er schnell

hin- und herbewegt wird? Wenn Störungen auf den Signalleitungen sind?
Ich verstehe nicht, was Falk meint.

... nur noch 125 Takte. Für die reine Quadraturdekodierung reichts
vielleicht. aber er will ja noch die Anzeige machen ...
Die Anzeige muss ja nicht 80 kmal je Sekunde aktualisiert werden.

Dekodierung im Timer-Int., Rest dazwischen.

Gute Nacht - Peter

--
Für Privat-Email bitte Betreff mit "Usenet-Reh" beginnen lassen.
--
"Ein Mokka-Trüffel-Parfait mit einem Zitronencreme-Bällchen."

 

[Andreas Donner]

"Falk Brunner" <Falk.Brunner@gmx.de> schrieb:

Hardware soweit klar. Der Knackpunkt ist die Software. Mach mal, wir
werden
dann mal sehen.

Fertig. Jetzt hab ich's halt doch mal probieren müssen. AT90S2313 mit
16MHz. Abtastung, Dekodierung und Übersprungdetektion in einer
50ľs-Task, das reicht grenzwertig für 20kHz. Aufdröselung des
Anzeigezählers in 5 Ziffern plus Vorzeichen und Multiplexen der Anzeige
in der Hauptschleife. Warnung bei Übersprung und Bereichsübertretung
durch Anzeige mit abwechselnd blinkendem Zahlenwert und Strichen
"-----". Rückstellung der Einfachheit halber durch Reset. Belegung ist
71% von 2kB. Kein Pin mehr übrig ;-)

Also, wer macht mit?

MfG
Falk

--
Es gibt keine Neue Rechtschreibung. Es gibt eine Rechtschreibung und
eine neue Schreibweise. Ausserdem hätte ich lieber eine
Mathematikreform, dann wäre das Rechnen nicht so schwer.

 

[Falk Brunner]

"Peter Muthesius" <newsname@gmx.de> schrieb im Newsbeitrag
news:432c9ab8$0$18648$14726298@news.sunsite.dk...

Tach auch,

Nun, was ist denn Prellen? Hier beim Inkrementalgeber bedeutet das ...
Also, Du meinst nicht das Prellen mechanischer Kontakte, welches
natürlich auch bei mechanischen Kontakten in Encodern auftritt. (Zumal
ich ja von optischen Encodern sprach.)

Auch optische können prellen. Das ist dann zwar ein etwas anderer
Wirkmechanismus, aber das Ergebnis ist praktisch gleich. Stell dir vor, der
Encoder bleibt genau "auf der Kippe" stehen und die Welle vibriert ein
wenig. Schwupps, schon prellts.

... dass ein Kanal sehr schnell seinen Zustand wechselt, wesentlich
schneller als bei maximaler Drehzahl (Pulszahl).
Warum sollte ein Kanal schnell seinen Zustand wechseln? Wenn er schnell
hin- und herbewegt wird? Wenn Störungen auf den Signalleitungen sind?
Ich verstehe nicht, was Falk meint.

Siehe oben.

... nur noch 125 Takte. Für die reine Quadraturdekodierung reichts
vielleicht. aber er will ja noch die Anzeige machen ...
Die Anzeige muss ja nicht 80 kmal je Sekunde aktualisiert werden.
Dekodierung im Timer-Int., Rest dazwischen.

Soweit die (unvollständige) Theorie. Schon klar, deine MUX-Routine muss nur
sagen wir mal 500 mal pro Sekunde laufen (5 Stellen mit 100 Hz geMUXt).
Aber während deine MUX Routine läuft muss die Abtastung weiter laufen. Und
das wird kniffelig.

MfG
Falk