Hallo zusammen, Ich habe ein Problem beim C programmieren (MPLAB für PICs). Folgendes: Ich habe 2 Signale (z.B. Signal A und B) von einem Drehgeber. Soweit ich es verstanden habe, muss ich bei diesem Drehgeber nun die Flanken (pos. & neg.) erkennen und eine Variable (nenne ich sie mal postition) entweder in- oder dekrementieren, um meinen Richtungswechsel vom Drehgeber zu erfassen. Ich habe schon ein paar Beispiel Codes hier gefunden im Forum, jedoch wurden da Bibliotheken eingefügt die es im MPLABX nicht gibt. Wie realsiere ich das in einem halbwegs vernünftigen C-Code? Nun zu meiner Frage: Wie erfasse ich die Flanken des Drehgebers (Graycode)? Und wie kann ich die Richtungswechsel in einer Variable festhalten? Bin über jeden Beispiel-Code dankbar (wenn es geht mit ausführlichen Kommentar)
Angehängte Dateien:
-
output.JPG
25 KB
Jürg B. schrieb: > Ich habe ein Problem beim C programmieren (MPLAB für PICs). Dann zeig doch mal Dein Programm und erkläre Dein Problem.
Jürg B. schrieb: > Soweit ich es verstanden habe, muss ich bei diesem Drehgeber nun die > Flanken (pos. & neg.) erkennen Nein, du hast es nicht verstanden und offenbar auch nirgends nachgeschlagemn. Das Problem der Incrementaldecodererfassung ist gelöst: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 https://www.mikrocontroller.net/articles/Drehgeber Du brauchst nicht mehr den falschen Weg einschlagen.
Jürg B. schrieb: > Ich habe schon ein paar Beispiel Codes hier gefunden im Forum, jedoch > wurden da Bibliotheken eingefügt die es im MPLABX nicht gibt. Wie > realsiere ich das in einem halbwegs vernünftigen C-Code? Die Bibliotheken dürften für die Funktion nicht relevant sein. Dafür braucht man bestimmt keine. Bei einem Encoder der per Hand bedient wird, würde ich entgegen der mit großer Vehemenz propagierten Lösung einen Pin-Interrupt verwenden. Die im oben verlinkten Artikel angesprochenen Probleme sind in diesem Fall meiner Meinung nach nicht relevant. (Hardwareentprellung vorausgesetzt)
Volker S. schrieb: > würde ich entgegen der > mit großer Vehemenz propagierten Lösung einen Pin-Interrupt verwenden Pass auf das du nicht ans Kreuz genagelt wirst. Wenn du nicht den heiligen Peter Dannegger anbetest wirst du auf dem Scheiterhaufen verbrannt!
Volker S. schrieb: > Bei einem Encoder der per Hand bedient wird, würde ich entgegen der > mit großer Vehemenz propagierten Lösung einen Pin-Interrupt verwenden. Was sagt dir das Wort PRELLEN? Willst du den Prozessor mit einem delay() so lange in der ISR anketten, bis das vorbei ist? Gerade bei Handdrehzahl verpasst man wirklich nichts, wenn man alle ms die Signals anguckt.
Volker S. schrieb: > Bei einem Encoder der per Hand bedient wird, würde ich entgegen der > mit großer Vehemenz propagierten Lösung einen Pin-Interrupt verwenden. Ja, DU. Das sagt halt eine Menge über deine Unkenntnis aus.
Michael B. schrieb: > Volker S. schrieb: >> Bei einem Encoder der per Hand bedient wird, würde ich entgegen der >> mit großer Vehemenz propagierten Lösung einen Pin-Interrupt verwenden. > > Ja, DU. > > Das sagt halt eine Menge über deine Unkenntnis aus. Und die willst du jetzt mit Arroganz bekämpfen? Viel Glück. Vielleicht erzählst du einfach jedem den du siehst "Haha, bist du doof!".
Wolfgang schrieb: > Volker S. schrieb: >> Bei einem Encoder der per Hand bedient wird, würde ich entgegen der >> mit großer Vehemenz propagierten Lösung einen Pin-Interrupt verwenden. > > Was sagt dir das Wort PRELLEN? > Willst du den Prozessor mit einem delay() so lange in der ISR anketten, > bis das vorbei ist? Das mit dem "Entprellen vorausgesetzt" hast du jetzt absichtlich aus dem Zitat weg gelassen oder? Die reflexartigen Reaktionen waren mir schon im Vornherein klar, aber manchmal kann ich es halt trotzdem nicht lassen ;-) > Gerade bei Handdrehzahl verpasst man wirklich nichts, wenn man alle ms > die Signals anguckt. Mit einem Pin-Interrupt verpasst man auch nichts, ohne alle paar ms ...
Ich habe das auch in einem käuflich erwerbbaren Produkt mit Interrupt drin. Allerdings Sperre ich den jeweiligen Interrupt nach auftreten für eine gewisse Zeit. Damit ist ein Deadlock durch 100% Interrupt auch ausgeschlossen und unterscheidet sich zum polling nur dadurch das im Stillstand keine Laufzeit benötigt wird und das man noch den genauen Zeitpunkt des Zuatandwechsels bestimmen kann ( wenn man möchte). Und bevor jetzt wieder welche kommen wo sagen das geht so nicht, doch das geht so. Und zwar locker bis 240kHz. Mit Vibrationen in einer Industrieanlage incl. der ganzen EMV von FUs usw. Stückzahl 50k ohne einen Serviceeinsatz.
Es gibt natürlich auch Drehgeber, die überhaupt nicht prellen, seien es optische oder magnetische. Die mit den mechanischen Kontakten sind die, auf die sich der Drehgeber Artikel vor allem bezieht. Industrielle Geber mit Quadratur Ausgängen sind so konzipiert, das sie direkt an eine SPS oder so passen - da prellt am Ausgang nix.
Selbst wenn es kein Kontaktprellen gibt, kann es immer Zittereffekte am Schaltpunkt geben, die Fehler produzieren. Wer will sich mit der ganzen Wackelproblematik überhaupt befassen, wenn sie mit ein paar zusätzlichen Zeilen Software gar nicht auftritt -> Pfuscher.
batman schrieb: > Selbst wenn es kein Kontaktprellen gibt, kann es immer Zittereffekte am > Schaltpunkt geben, die Fehler produzieren. Dann trink weniger Kaffee oder geh zum Arzt ;-)
Viele Poller sind ja noch nicht mal in der Lage das richtige Intervall für das Polling zu bestimmen ;-) Volker S. schrieb im Beitrag #4201477 Beitrag "Re: Drehimpulsgeber": > Versprochenes Beispiel eines Signalverlaufs Haben sich vermutlich seltenst mit der Hardware beschäftigt (Oszi, messen...) sondern immer irgendwas nachgelabert ;-) Dass die Flanken von so einem Hand-Drehgeber auf den Rastpunkten liegen habe ich auch in der Realität noch nie gesehen. Egal wie das im Datenblatt dargestellt wird. @Jürg: Sorry, war klar das das so endet und nicht mehr auf deine Frage eingegangen wird.
Meine Fresse. Diese Vehemenz mit der hier Einige die nachweislich schlechte Flankeninterruptlösung verteidigen ist krank. Als ob es einen Prozessor jucken würde, während er nichts zu tun hat regelmässig die Encoder abzufragen. Und WENNer was zu tun hat muss er trotzdem genug Rechenzeit übrig gaben um die Encoder auszuwerten. Als ob es um Kaffee gehen würde, wenn Encoderwellen in Maschinen vibrieren. Als ob jemand, der angeblich nicht das richtige Intervall zum Polling ermitteln kann, in der Lage wäre aus der Laufzeitlänge der Interruptfunktion die maximale Strichrate zu ermitteln. Ja, wenn man vorher in Hardware entprellt kann man auf Flanken reagieren, wenn man nach einer Flanke die Prellzeit Interupts sperrt wird der Prozessor nicht überrannt, aber all das ist erheblich aufwändiger als es gleich richtig zu machen. Diese Flankenerkenner erinnern an religiös verbrämte Alttestamentarler.
Volker S. schrieb: > @Jürg: Sorry, war klar das das so endet und nicht mehr auf deine Frage > eingegangen wird. Ich korrigiere das mal ;-) Jürg B. schrieb: > Bin über jeden Beispiel-Code dankbar (wenn es geht mit ausführlichen > Kommentar) Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR" Ist allerdings für AVR, sollte aber übertragbar sein. An Stelle des Schrittmotors kann man auch einen Drehgeber nehmen; die Drehdynamik kann man auch entfernen. Es gibt noch mehr Beispiele, die ich auf die Schnelle aber nicht finde. Das Geschreie der Poller mußt Du überlesen - der übliche Kindergarten ;-)
batman schrieb: > Genau, Erwachsene löten lieber anstatt zu denken. Manchmal schon. Da bleiben weniger Zweifel ;-)
m.n. schrieb: https://www.mikrocontroller.net/attachment/highlight/211945 > Ist allerdings für AVR, sollte aber übertragbar sein. An Stelle des > Schrittmotors kann man auch einen Drehgeber nehmen; die Drehdynamik kann > man auch entfernen. > Es gibt noch mehr Beispiele, die ich auf die Schnelle aber nicht finde. > Das Geschreie der Poller mußt Du überlesen - der übliche Kindergarten > ;-) Erstmal danke für das Beispiel: Jedoch sind noch ein paar Unklarheiten aufgetreten: #define PHASE_A 2 // an PORTD.2 (PCINT18) #define PHASE_B 3 // an PORTD.3 (PCINT19) Ist das, dass gleiche wie? #define PHASE_A RD2 // an PORTD an PIN2 #define PHASE_B RD3 // an PORTD an PIN3` ISR(PCINT2_vect) Was ist mit dem Inhalt der Klammer gemeint? int8_t temp, neuer_zustand = PIND; // zunaechst Zustand der beiden Phasen lesen die Schreibweise für Microchip wäre dann... char temp, neuer zustand = PORTD; (wäre anstatt PORTD Auch diese schreibweise gültig => z.B. (PORTD & 0b00000110)?) DDRD &= ~MASKE; // Phasen wieder auf Eingang schalten Dieses DDRD kommt sehr oft vor in AVR was bedeutet, dass genau? PCIFR = BIT(PCIF2); // duerfte nicht gesetzt sein, dennoch loeschen Ist dieses PCIF2 ein Bit des Interrupts, dass nach jeder Flankenänderung wieder auf Null gesetzt wird? Und ich bedanke mich nochmals für die bisherigen Antworten und die kommenden Antworten!
Jürg B. schrieb: > m.n. schrieb: > https://www.mikrocontroller.net/attachment/highlight/211945 >> Ist allerdings für AVR, sollte aber übertragbar sein. An Stelle des >> Schrittmotors kann man auch einen Drehgeber nehmen; die Drehdynamik kann >> man auch entfernen. >> Es gibt noch mehr Beispiele, die ich auf die Schnelle aber nicht finde. >> Das Geschreie der Poller mußt Du überlesen - der übliche Kindergarten >> ;-) > > Erstmal danke für das Beispiel: > > Jedoch sind noch ein paar Unklarheiten aufgetreten: > > #define PHASE_A 2 // an PORTD.2 (PCINT18) > #define PHASE_B 3 // an PORTD.3 (PCINT19) > Ist das, dass gleiche wie? > #define PHASE_A RD2 // an PORTD an PIN2 > #define PHASE_B RD3 // an PORTD an PIN3` eher #define PHASE_A PORTDbits.RD2 > Dieses DDRD kommt sehr oft vor in AVR was bedeutet, dass genau? Data Direction Register -> TRIS Was für einen PIC hast du denn? Wenn du dich nach all dem hier tatsächlich traust Interrupts zu verwenden, dann schau mal da http://www.hs-ulm.de/users/vschilli/Mikrocontroller/uCQ/_downloads/uC_quick-X.pdf Kapitel 5.3.2 (der Panasonic Typ)
m.n. schrieb: > Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR" Wow ist DAS eine kranke Lösung. SOWOHL Timerinterrupt ALS AUCH Flankeninterrupts benutzt, und natürlich wurde 'vergessen' darauf hinzuweisen, daß dieses Programm NUR mit bereits hardwareentprellten Eingängen klar kommt weil sonst der Prozessor mit Interrupts überrannt wird, UND dann ist es noch eine Seite lang. Kann man mehr Katastrophen in einem Programm unterbringen ? Volker S. schrieb: > Wenn du dich nach all dem hier tatsächlich traust Interrupts zu > verwenden, Wenn du ihn aufforderst, Schrauben unbedingt mit einem Hammer einzuschlagen.... Er wäre blöd.
Jürg B. schrieb: > #define PHASE_A RD2 // an PORTD an PIN2 Es soll Pin2 am PortD sein, wie Dein Kommentar es auch sagt. > ISR(PCINT2_vect) Was ist mit dem Inhalt der Klammer gemeint? Das ist die Interuptroutine über die Sprungtabelle zu PCINT2, welche PCINT16-PCINT23 behandelt (entspricht PortD.0 - PortD.7). PCIF2 ist das Flag, was den PCINT2 auslöst, wenn gesetzt. Beim AVR ist: DDRD das Datenrichtungsregister von PortD; eine '1' bedeutet Ausgang PORTD ist das Ausgangsregister von PortD; eine '1' setzt den Ausgang PIND liest die Pins von PortD, d.h. den tatsächlichen Zustand an den Eingängen. PortD würde nur das Ausgangsregister zurücklesen: falsch! > PCIFR = BIT(PCIF2); // duerfte nicht gesetzt > sein, dennoch loeschen > Ist dieses PCIF2 ein Bit des Interrupts, dass nach jeder Flankenänderung > wieder auf Null gesetzt wird? Es wird bei jeder Flankenerkennung gesetzt und per Hardware beim Aufruf der ISR gelöscht. Den Befehl ist ein Überbleibsel aus anderen Funktionen und kann weggelassen werden. Ich hoffe, daß Du den Ablauf bei Deinem PIC 1:1 umsetzen kannst.
m.n. schrieb: > Das Geschreie der Poller mußt Du überlesen - der übliche Kindergarten "Geh nicht bei Rot über die Straße!" hatten sie alle noch gerufen... ;-) Zum Thema "dynamischer Encoder" hätte ich hier auch noch einen Vorschlag: http://www.lothar-miller.de/s9y/categories/54-Encoder Das läuft seit Jahren mit unterschiedlichen Encodern problemlos. Das wars. Und jetzt weiter mit den Pinchange-Interrupts.
Das is ja einfach! :-) Auf welche Schrittweiten kommst du da maximal bei einer Handdrehung?
batman schrieb: > Auf welche Schrittweiten kommst du da maximal bei einer Handdrehung? Das kann man sich ja programmieren. Aber ich stelle damit z.B. Midiwerte ein, und bei einem 16er Encoder müsste ich da auch bei 4-fach Auswertung mindestens 2 mal drehen um von 0 auf 127 zu kommen. Das geht mit Dynamik ganz locker auf einmal ohne Umgreifen...
Lothar M. schrieb: > Zum Thema "dynamischer Encoder" hätte ich hier auch noch einen > Vorschlag: > http://www.lothar-miller.de/s9y/categories/54-Encoder Da mach ich mir doch gleich mal ein Lesezeichen drauf :-) Danke schön!
Volker S. schrieb: > Die reflexartigen Reaktionen waren mir schon > im Vornherein klar, aber manchmal kann ich es halt trotzdem nicht lassen Du bist also ein Troll? Dann schlag doch als nächstes achteckige Räder vor. Die sind doch viel besser als die vor vielen Jahren erfundenen runden Räder (Entprellung an den Ecken voaorausgesetzt).
Harald W. schrieb: > Du bist also ein Troll? In gewisser Weise schon ;-) Lothar M. schrieb: > Und jetzt weiter mit den Pinchange-Interrupts. Pinchange Interrups mag ich jetzt persönlich nicht so....
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.