Mein Haustier ärgert sich, wenn die Quadraturdecodierung in Software durchgeführt wird. In der Software kann der Decoder häufig nicht mithalten, insbesondere wenn die Pulsfrequenz schnell ist oder die MCU viele andere Dinge tut. Ich habe viele Geräte gesehen, die Quadraturcodierer an einem Dateneingabeknopf verwenden, und es funktioniert die meiste Zeit einwandfrei. Der Decoder übersprang jedoch Impulse, wenn die MCU etwas tun musste, z. B. den Bildschirm aktualisieren oder über RS-232 sprechen.
Ich mache Quadraturdecodierung in einem FPGA. Ein 50K Gate Xilinx Spartan-3A kostet weniger als 10 US-Dollar und kann mehr Kanäle dekodieren als Pins. Und das mit einer Quadraturpulsfrequenz über 1 MHz. Es gibt keine MCUs für ähnliche oder günstigere Kosten, die dies tun können.
Bearbeiten: Was unten folgt, ist eine Zusammenfassung vieler Kommentare und einige weitere Ausführungen von meiner Seite. Genießen!
Es ist wahr, dass Sie einen Software-Ansatz durchführen können, wenn die Pulsfrequenz langsam genug ist. Wenn dies erledigt ist, müssen Sie sicherstellen, dass die "Eckfälle" abgedeckt sind. Dinge wie Interrupts für andere Peripheriegeräte (wie UARTs, ADCs usw.) können beeinflussen, wie oft Sie die Quadraturdaten abtasten, wodurch der Quadraturdecodierungsprozess gelegentlich Impulse verfehlt. Diese fehlenden Impulse sind für einige Anwendungen, wie z. B. einen Dateneingabeknopf, "in Ordnung", stören mich aber immer noch.
@Leon Heller mag die XMOS-Prozessoren für so etwas wirklich . Für diejenigen, die es nicht wissen, ist das XMOS-Zeug im Grunde eine einfache, aber superschnelle MCU. Wo die meisten MCUs im Bereich von <25 MIPS laufen, drängt das XMOS-Zeug auf 500 MIPS. XMOS macht nicht viele hardwarebasierte Peripheriegeräte wie UARTs. Stattdessen "bit-bang" sie es und machen den UART in Software. Sie bieten auch Dinge wie USB und 10 MBit / s Ethernet. Ok, ich vereinfache das sehr, aber du verstehst, worum es geht. Hier ist meine Meinung: Es gibt FPGA-Leute und es gibt CPU-Leute. Wenn Sie ein CPU-Typ sind und keine FPGAs mögen, ist der XMOS-Prozessor möglicherweise das Richtige für Sie.
Das Thema Gray-Codes in einer FPGA-Implementierung wurde angesprochen und die Up / Down-Positionszähler in Gray-Code implementiert. Es gibt normalerweise zwei Gründe für die Verwendung von Gray-Codes: Wenn eine asynchrone Logik ausgeführt wird (2 oder mehr Takte) oder wenn die Zähler weniger Logik benötigen. Normalerweise hätten Sie keine asynchrone Logik im FPGA (außer das Abtasten der Quadraturdaten an den Eingangspins), und das FPGA verfügt bereits über superschnelle Übertragsketten (auch als binäre Addierer bezeichnet). Unter normalen Umständen sind hierfür keine Gray-Code-Zähler erforderlich.
Sie können hierfür anstelle eines FPGA eine CPLD verwenden. Dies würde für 1 oder 2 Quadraturdecoder funktionieren, aber wenn Sie mehr Decoder hinzufügen, wird die Schnittstelle zu einer MCU komplexer. FPGAs sind dafür gut geeignet, da die MCU-Schnittstelle SPI oder eine andere einfache Sache sein kann, die nicht Dutzende von Pins auf der MCU belegt.
Der "richtige" Weg, dies in einem FPGA zu tun, besteht darin, dass das FPGA einen einfachen 8-16-Bit-Zähler hat, der die Position verfolgt. Dieser Zähler wird nach der Initialisierung nie und manchmal auch dann nicht zurückgesetzt. Software (SW) fragt diese Position von Zeit zu Zeit ab und zeichnet die "vorherige Position" auf. Wenn Sie die aktuelle Position nehmen und die vorherige Position subtrahieren, wird der Software mitgeteilt, wie weit sich die Position geändert hat.
Der Grund, warum der Positionszähler niemals zurückgesetzt wird, ist, dass wir versuchen, ein "destruktives Lesen" zu vermeiden. In diesem Fall liest die CPU ein Register, wodurch etwas Irreversibles passiert - beispielsweise das Löschen eines Positionszählers. Manchmal sind destruktive Lesevorgänge unvermeidlich, wie beim Lesen eines FIFO, aber im Allgemeinen möchten Sie sie vermeiden. Das Denken dahinter geht über diesen Beitrag hinaus. Ich habe versucht, eine gute Webseite zu finden, auf der sie besprochen werden, aber ich bin gescheitert. Es tut uns leid.
Wenn ich unten über die Zählrate spreche, meine ich, wie schnell der Positionszähler nach oben oder unten gehen kann. Aufgrund der Quadratur der Sache beträgt die "Pulsfrequenz" ein Viertel der Zählrate. Ich gehe davon aus, dass wir für jeden vollen Puls viermal hoch / runter zählen können. Ich weiß, dass es andere Möglichkeiten zum Zählen gibt (eine Zählung pro vollem Impuls), aber ich ignoriere sie aus Prinzip.
Ohne Berücksichtigung des XMOS-Prozessors (der im Kontext der nächsten Absätze eher einem FPGA ähnelt) werden MCUs auf eine maximale Zählrate von weniger als 500 Hz und in vielen Fällen von weniger als 100 Hz begrenzt. Natürlich kann es einige Ausreißer geben, die höher als 1 kHz werden, aber für die meisten Menschen ist das schwierig. Für Ihre typische MCU ist es gut, über 100 Hz zu kommen, vorausgesetzt, die MCU ist nicht für die Quadraturdecodierung vorgesehen.
Ein typischer Dateneingabeknopf hat 12 bis 20 Impulse pro Umdrehung oder 48 bis 80 Zählungen pro Umdrehung. Angenommen, der Knopf hat einen Durchmesser von 1 Zoll, könnte eine typische, aber übereifrige Person etwa 4 Umdrehungen pro Sekunde erzielen, wenn sie versucht, durch viele Daten zu scrollen. Das entspricht einer Zählrate von 192 bis 320 Hz. Immer noch im Rahmen einer MCU, aber nur knapp und nur mit sorgfältiger Programmierung.
Ein FPGA kann, abhängig davon, wie genau die Logik geschrieben ist, Zählraten von mehr als 100 MHz verarbeiten. Ich habe meine Logik für Zählraten von bis zu etwa 50 kHz geschrieben, aber sie kann viele Quadraturdecoder in sehr wenig Logik ausführen. In einem Xilinx Spartan-3-FPGA sind etwa 50 Slices und 1 Block-RAM erforderlich, um 32 bis 512 Decoder auszuführen (Ihnen gehen die Pins aus, bevor Ihnen die Logik ausgeht).
Also, was ist besser, FPGA, MCU oder XMOS? Wie immer kommt es darauf an. Dies hängt nicht nur von den üblichen Faktoren wie Zählrate und Anzahl der Decoder ab, sondern auch davon, was der Designer bequem verwendet und was sich sonst noch im System befindet. Ich bevorzuge FPGA, aber das ist genau der Typ, der ich bin! :) :)