Daher kann man obigen Code auch wie folgt umschreiben. Damit erfolgt die Erfassung auf jeden Fall zeitgleich, allerdings handelt man sich die Unschönheit ein, dass man im entsprechenden Makro auf eine interne Variable der Auswertefunktion zugreift. (Als „saubere“ Alternative müsste man den Code so umschreiben, dass das Erfassen der Werte und die Auswertung der gewünschten Spur in separate inline-Funktionen getrennt werden.)
Das zeitgleiche einlesen verstehe ich ja, aber welchen weiteren Einfluss
hat dieses Herangehen auf den Code?
Einlesen (erfassen) und Auswerten würde doch weiterhin innerhalb der
Timer-ISR ablaufen und der Zugriff auf das (oder eben die) Ergebnisse
könnten vom Makro, mit geblockten Interrupts, ausgelesen werden.
Eigentlich also genau wie im vorangestellten Beispiel gezeigt, nur dass
die Eingangszustände der beiden Spuren noch irgendwie zu maskieren
wären.
Also, was steckt den hinter dem Hinweis des Autors?
Ralf schrieb:> Das zeitgleiche einlesen verstehe ich ja, aber welchen weiteren Einfluss> hat dieses Herangehen auf den Code?
Nicht viel. Anstatt 2x auf PORTA zuzugreifen (durch die Makros PHASE_A
und PHASE_B) greift man nur einmal auf PINA zu und dann 2x auf diese
Variable.
Das ist halt ein MÜ genauer, weil beide Signale EXAKT gleichzeitig
erfaßt werden.
Ich hab den Beispielcode mal geändert. So ist es akademisch schön ;-)
Falk B. schrieb:> Das ist halt ein MÜ genauer, weil beide Signale EXAKT gleichzeitig> erfaßt werden.
Wobei es ein "EXAKT gleichzeitig" im tiefsten Inneren schon im Prinzip
nicht gibt. Denn allein schon die Laufzeit vom Pin zum IO-Register wird
leicht unterschiedlich sein. Aber gut, das ist rein philosophisch und
das Haar hiermit gespalten. ;-)
Und wo ich mir die Sache mal so überlege, dann könnte sogar die dortige
Aussage "beim Auswerten ... beachten, dass die beiden Signalleitungen
des Drehgebers möglichst zeitgleich erfasst werden" grundlegend falsch
sein.
Ich meine, man könnte bei einem 1ms-Timerinterrupt ohne jeglichen
Schaden auch 950µs zwischen dem Einlesen der beiden
"zusammengehörigen" Pegel warten, wenn der Drehgeber "hinreichend oft"
abgetastet wird. Und "hinreichend oft" muss er ja sowieso abgetastet
werden, dass keine Schritte verloren gehen.
Ich muss das mal bei Gelegenheit ausprobieren...
Lothar M. schrieb:> leicht unterschiedlich sein. Aber gut, das ist rein philosophisch und> das Haar hiermit gespalten. ;-)
Jaja ;-)
> Und wo ich mir die Sache mal so überlege, dann könnte sogar die dortige> Aussage "beim Auswerten ... beachten, dass die beiden Signalleitungen> des Drehgebers möglichst zeitgleich erfasst werden" grundlegend falsch> sein.
Nö.
> Ich meine, man könnte bei einem 1ms-Timerinterrupt ohne jeglichen> Schaden auch 950µs zwischen dem Einlesen der beiden> "zusammengehörigen" Pegel warten, wenn der Drehgeber "hinreichend oft"> abgetastet wird.
Jain. Mit deiner 950us Pause sinkt aber die effektive Abtastrate bzw.
die erzielbare Abtastrate. D.h. auch, je mehr du dich mit der
Signalfrequenz dem theoretischen Maximum näherst, umso eher verschluckt
sich dein Dekoder wegen der ungleichen Abtastung.
OK, im Beispiel ist das echt akademisch, denn der Doppelzugriff auf das
IO-Register erfolgt innerhalb weniger CPU-Takte, da ist kaum mehr als ne
us dazwischen.
> Und "hinreichend oft" muss er ja sowieso abgetastet> werden, dass keine Schritte verloren gehen.> Ich muss das mal bei Gelegenheit ausprobieren...
Hmmm, müßte ich auch mal machen, klingt nach einer guten Anwendung für
meinen neuen FY6900, Quadratursignale erzeugen!
Falk B. schrieb:> Das ist halt ein MÜ genauer, weil beide Signale EXAKT gleichzeitig> erfaßt werden.
Ist es nicht. Solange zwischen den beiden Abtastungen nicht auf beiden
Kanälen ein Pegelwechsel statt findet, ist das beim Gray-Code völlig
egal und der Fehler, den du zusätzlichen meinst zu machen, geht im
Quantisierungsrauschen unter.
Lothar M. schrieb:> Und "hinreichend oft" muss er ja sowieso abgetastet> werden, dass keine Schritte verloren gehen.
Die Grenzbedingung ist einfach: zwischen 2 Leseoperationen darf nur 1
Pegelwechsel stattfinden, also bestimmt die Abtastrate die maximale
Zählfrequenz - irgendwie logisch. Das gilt auch wenn man schnelle
Hardwarezähler mit Quadratureingang verwendet und z.B. mit 10 MHz
taktet, es gibt IMMER eine maximale Zählfrequenz. Die muss eben über der
maximalen Verfahrgeschwindigkeit einer Maschinenachse liegen, bei
Drehgebern zur manuellen Eingabe ist das dagegen weitgehend egal, man
dreht solange am Knopf bis der Wert erreicht ist, verlorene Impulse
spielen garkeine Rolle.
Ein Motor mit 3000 U/min und einem 1000-Schritte-Encoder liefert schon
50 kHz und für eine CNC-Steuerung ist das garnichts. Da ist mit einem
1ms-Timer nichts zu machen.
Georg
Falk B. schrieb:> icht viel. Anstatt 2x auf PORTA zuzugreifen (durch die Makros PHASE_A> und PHASE_B) greift man nur einmal auf PINA zu und dann 2x auf diese> Variable.> Das ist halt ein MÜ genauer, weil beide Signale EXAKT gleichzeitig> erfaßt werden.
Ok, soweit war das ja klar. Ich hatte Probleme mit dem Satz und dem
unschönen Nebeneffekt, aber der ist ja jetzt weg. :-)
Vielen Dank
Lothar M. schrieb:> Wobei es ein "EXAKT gleichzeitig" im tiefsten Inneren schon im Prinzip> nicht gibt. Denn allein schon die Laufzeit vom Pin zum IO-Register wird> leicht unterschiedlich sein. Aber gut, das ist rein philosophisch und> das Haar hiermit gespalten. ;-)>> Und wo ich mir die Sache mal so überlege, dann könnte sogar die dortige> Aussage "beim Auswerten ... beachten, dass die beiden Signalleitungen> des Drehgebers möglichst zeitgleich erfasst werden" grundlegend falsch> sein.
Au weia. Was für ein Unsinn.
Also:
1. Dir sollte bekannt sein, daß ein µC ein getaktetes System ist. Daraus
folgt, daß auch der Zustand der Pins (und zwar aller Pins, die an
allen Ports eines gemeinsamen Peripheriebusses auf dem Silizium hängen)
mit demselben Takt abgetastet (neudeutsch: gesamplet) werden. Das IST
gleichzeitig, auch wenn hier klar wird, daß dabei eine prinzipbedingte
Zeitunsicherheit herrscht, die von der Periode des Abtast-Taktes
abhängt. Aber da diese sich im Nanosekunden-Bereich abspielt, ist sie
hier egal.
Dein Gedanke "vom Pin zum IO-Register" ist damit gegenstandslos.
Und die beiden Signale vom DG müssen tatsächlich "ausreichend
zeitgleich" erfaßt werden. Daran hängt nämlich die Richtungs-Aussage
direkt ab.
Normalerweise sind DG so konstruiert, daß der mechanische Winkel-Abstand
der Signale möglichst groß ist, so daß auch deren zeitlicher Abstand
beim Drehen ebenfalls möglichst groß ist. Aber der ist sehr viel kleiner
als der Betätigungsabstand bei gewöhnlichen Tasten.
DG werden recht oft recht schnell gedreht, so daß es bei rastenden DG
einen "Ratsch" gibt. Da kannst du mal annehmen, daß da in 0.1 Sekunden
mehr als 10 Rastungen überdreht werden, macht also mehr als 40
Zustandsänderungen aus (bei DG mit feinerer Auflösung entsprechend
mehr). Jetzt kriegst du hoffentlich einen Eindruck darüber, was hier als
zeitnah gelten mag.
Soviel zu deinem Gedanken, daß diese Zeitgleichheit grundlegend falsch
sein könnte.
Nein, sie ist nicht falsch, sondern grundlegend richtig.
Das möglichst zeitgleiche Abtasten ist essenziell.
Widrigenfalls landet man nämlich im Umschaltprellen des jeweils anderen
Kanals oder gar dahinter. Das mag bei neuwertigen DG noch harmlos sein,
bei gut gebrauchten DG wird das jedoch zum Abenteuer. Da wäre das
wirksamste Gegenmittel eine rein analoge Entprellung, sprich
Tiefpaßfilter.
W.S.
Georg schrieb:> Ein Motor mit 3000 U/min und einem 1000-Schritte-Encoder liefert schon> 50 kHz und für eine CNC-Steuerung ist das garnichts. Da ist mit einem> 1ms-Timer nichts zu machen.
Ein 1ms-Timer ist in so einem Fall sicher das falsche Werkzeug.
Auf der anderen Seite bekommt das ein passender Arduino mit seiner
vorhandenen Hardware spielend hin.
W.S. schrieb:> Widrigenfalls landet man nämlich im Umschaltprellen des jeweils anderen> Kanals oder gar dahinter.
Der Gray-Code wurde entwickelt, um gegen Prellen immun zu sein. Verloren
hast du natürlich, wenn das Prellen länger dauert als die Drehung bis
zum Flankenwechsel auf dem anderen Kanal.
W.S. schrieb:> Das IST gleichzeitig, auch wenn hier klar wird, daß dabei eine> prinzipbedingte Zeitunsicherheit herrscht, die von der Periode des> Abtast-Taktes abhängt. Aber da diese sich im Nanosekunden-Bereich> abspielt, ist sie hier egal.
Wenn sie im Nanosekunden schlicht "egal" ist, warum sollte sie dann im
Mikrosekundenbereich derart schädlich sein, dass solche Betrachtungen
gleich mal "unsinnig" sind?
> Das möglichst zeitgleiche Abtasten ist essenziell.
Aber nur für möglichst hohe Drehgeschwindigkeiten, nicht für das
Verfahren an sich.
Ich sagte ja, dass natürlich prinzipiell schnell genug abgetastet
werden muss. Wenn sich also jemand an der 1ms stört, dann nehmen wir
halt 10µs und tasten den einen Kanal jeweils sofort nach dem Interrupt
ab und den anderen nach 9µs.
Aber seis drum: ich bin selber draufgekommen, und das Problem sind hier
lediglich tatsächlich solche Billig-Encoder, die ihre Schritte bei
gleichmäßiger Drehung völlig asymmetrisch ausgeben:
1
vvv hier geht es eng her vvv
2
A _____----------------_________________----------------_____________
3
B _____________---------________________________---------____________
Der finale Witz ist, dass bei solchen Gebern eine zeitliche Verzögerung
eines Kanals beim Drehen in die eine Richtung "hilft" und bei Drehen in
die andere "schadet":
1
"vorwärts" --> besseres Signal, weil Flanken weiter "auseinander" rücken
2
vvvv vvvv
3
A _____----------------_________________----------------_____________
4
B ______________---------________________________---------___________
5
6
"rückwärts" --> schlechteres Signal, weil Flanken enger "zusammen" rücken
7
vv vv
8
A _____----------------_________________----------------_____________
9
B ____________---------________________________---------_____________
> Jetzt kriegst du hoffentlich einen Eindruck darüber, was hier als> zeitnah gelten mag.
Nur zur Info: ich weiß, wie man Drehgeber abtastet. Sowohl die teuren
wie auch die billigen. Sowohl die schnellen wie auch die langsamen.
Thread beobachten
Seitenaufteilung abschalten