Hallo zusammen, folgendes Problem quält mich gerade: Ich habe einen Drehgeber, der pro Umdrehung 1000 Rechtecksignale liefert. Mit einem Raspberry Pi B kann ich ihn nicht sinnvoll auswerten, da die Latenz an den GPIOs zu hoch ist bzw. ich schlicht nicht schnell genug pollen kann (C++, pigpio/wiringPi). Es werden immer wieder Signale übersehen, das Richtungssignal "springt" in der Folge. Eine brauchbare Geschwindigkeitserkennung ist so natürlich auch nicht möglich. Ich überlege nun, ob es sinnvoll ist, die Auswertung einem dezidierten Mikrocontroller (ein kleiner AVR) zu überlassen oder ob der damit auch überfordert ist. Nun steht im Wiki-Artikel zu Drehgebern, daß bei höheren Geschwindigkeiten oder Auflösungen auch ein µC überfordert ist. Nur, was ist "höher"? 1000 Signale/U sind IMHO schon recht viel, die Geschwindigkeit liegt im Moment aber noch bei wenigen U/min. Könnte das ein kleiner AVR stemmen oder sollte ich mich gleich nach einer diskreten Decoderlogik umsehen? Was meint Ihr? Schon mal Danke für Eure Antworten :) 42m
Nimm doch nen STM32F4, der hat das in Hardware gegossen und zusätzliche Fehlererkennung eingebaut.
Es gibt sogar billige Prozessoren, die können das in Hardware. Register auslesen und fertig.
uwe schrieb: > Nimm doch nen STM32F4, der hat das in Hardware gegossen und zusätzliche > Fehlererkennung eingebaut. Hallo Uwe, danke für den Hinweis. Ich schau mir mal das Datenblatt an. Was mir bei den STM, die ich jetzt auf die Schnelle bei Farnell gefunden habe, nicht gefällt ist die für einen Versuchsaufbau blöde Lötbarkeit. 42m
Michael Krauth schrieb: > 1000 Signale/U sind IMHO schon recht viel, die Geschwindigkeit liegt im > Moment aber noch bei wenigen U/min. wenige U/min ist leider keine sehr präzise Angabe. Der eine versteht darunter 6 der andere 6000. Bei 6 U/min hast du ein Signal mit von 100 Hz, was sich problemlos (selbst mit Arduino-IDE) verarbeiten lässt. Bei 6000 U/min hast du 100 kHz. Da ist dann schon etwas mehr Geschick gefragt.
Karl schrieb: > wenige U/min ist leider keine sehr präzise Angabe. Der eine versteht > darunter 6 der andere 6000. Äh, ja, mein Fehler, sorry. Im Moment komme ich auf unter 10 U/min. Später werden es auch nicht mehr als 100 bis 150 U/min. > Bei 6 U/min hast du ein Signal mit von 100 Hz, was sich problemlos > (selbst mit Arduino-IDE) verarbeiten lässt. Bei 6000 U/min hast du 100 > kHz. Da ist dann schon etwas mehr Geschick gefragt. Ich versuche es einfach mal mit dem ATmega 328P, den ich hier noch rumliegen habe. Schlechter als mit dem Pi kann es ja eigentlich nicht werden :) 42m
@ Michael Krauth (michael_k42) >Mit einem Raspberry Pi B kann ich ihn nicht sinnvoll auswerten, da die >Latenz an den GPIOs zu hoch ist bzw. ich schlicht nicht schnell genug >pollen kann (C++, pigpio/wiringPi). Das ist ja auch eine Kindergartensprache. >Ich überlege nun, ob es sinnvoll ist, die Auswertung einem dezidierten >Mikrocontroller (ein kleiner AVR) zu überlassen Kann man machen. >oder ob der damit auch >überfordert ist. Nö. Aber bitte nicht wieder Arduino Sachen, sondern echtes C. >Nun steht im Wiki-Artikel zu Drehgebern, daß bei höheren >Geschwindigkeiten oder Auflösungen auch ein µC überfordert ist. Nur, was >ist "höher"? >1000 Signale/U sind IMHO schon recht viel, die Geschwindigkeit liegt im >Moment aber noch bei wenigen U/min. Lächerlich wenig. >Könnte das ein kleiner AVR stemmen Ja. >oder sollte ich mich gleich nach >einer diskreten Decoderlogik umsehen? >Was meint Ihr? Nimm einen kleinen AVR mit UART, pack den Dekoder dort rein und sende den Zählerstand periodisch per UART an deinen Himbeerkuchen.
Falk Brunner schrieb: >>pollen kann (C++, pigpio/wiringPi). > > Das ist ja auch eine Kindergartensprache. C++? Assembler ist dann vermutlich Grundschulniveau ... > Nö. Aber bitte nicht wieder Arduino Sachen, sondern echtes C. Wieso wieder? Meine AVR habe ich bislang immer in C programmiert. > Lächerlich wenig. >>Könnte das ein kleiner AVR stemmen > > Ja. Gut zu wissen. Danke.
Michael Krauth schrieb: > Nun steht im Wiki-Artikel zu Drehgebern, daß bei höheren > Geschwindigkeiten oder Auflösungen auch ein µC überfordert ist. Nur, was > ist "höher"? > 1000 Signale/U sind IMHO schon recht viel, die Geschwindigkeit liegt im > Moment aber noch bei wenigen U/min. Man muß ja nicht Alles glauben: Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88" oder mit Arduino und 'richtigem' C: Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR" Den Schrittmotor ersetzt man durch die A/B-Signale und die Dynamik kann man weglassen.
@ Michael Krauth (michael_k42) >>>pollen kann (C++, pigpio/wiringPi). >> Das ist ja auch eine Kindergartensprache. >C++? Assembler ist dann vermutlich Grundschulniveau ... Nein, das wiringPI. Das basiert zwar auf C++, ist aber nicht sonderlich leistungsfähig. >> Nö. Aber bitte nicht wieder Arduino Sachen, sondern echtes C. >Wieso wieder? Meine AVR habe ich bislang immer in C programmiert. Siehe oben. wiringPI.
Falk Brunner schrieb: > Nein, das wiringPI. Das basiert zwar auf C++, ist aber nicht sonderlich > leistungsfähig. > Siehe oben. wiringPI. Da ich nicht anfangen möchte, im Kernel space rumzubasteln habe ich mich für eine fertige Lib entschieden. Bei Dir klingt es ein bisschen so, als sei es Kindergarten, wenn man nicht alles selber macht sondern sich auf vorgefertigte Bibliotheken verlässt. Aber ich bin sicher, Du meinst das nicht so. Daß wiringPi schwach auf der Brust ist, das glaube ich. Allerdings lesen sich die verschiedenen Berichte zum Thema GPIO beim Pi so, als sei das nicht alleine ein Problem einer bestimmten Lib sondern systemimmanent, zumindest wenn man den Pi mit Linux betreibt. 42m
@ Michael Krauth (michael_k42) >> Nein, das wiringPI. Das basiert zwar auf C++, ist aber nicht sonderlich >> leistungsfähig. >> Siehe oben. wiringPI. >Da ich nicht anfangen möchte, im Kernel space rumzubasteln habe ich mich >für eine fertige Lib entschieden. Was vollkommen OK ist. >Bei Dir klingt es ein bisschen so, als sei es Kindergarten, wenn man >nicht alles selber macht sondern sich auf vorgefertigte Bibliotheken >verlässt. Aber ich bin sicher, Du meinst das nicht so. Ist es auch nicht ;-) Wiring PI / Arduino hat schon seine Berechtigung. Es ist Lego in Software. Sicher ein schöne Sache für Einsteiger, aber irgendwann ist halt mal Schluss. >Daß wiringPi schwach auf der Brust ist, das glaube ich. Allerdings lesen >sich die verschiedenen Berichte zum Thema GPIO beim Pi so, als sei das >nicht alleine ein Problem einer bestimmten Lib sondern systemimmanent, >zumindest wenn man den Pi mit Linux betreibt. Das kommt noch dazu. Ich kenne zwar die Architektur vom Linux als auch vom Wiring nicht im Detail, aber ich ahne Schlimmes. Da wird selbst das Abfragen/Setzen eines einfach GPIOs zu einer Verwaltungsakt sondersgleichen, der durch mindestend ein halbes Dutzend Treiberschichten wandern muss. So würgt man auch eine 700 MHz CPU ab. Alles wird gut. Erst recht mit einem AVR ;-)
Falk Brunner schrieb: > Ist es auch nicht ;-) Puh, Glück gehabt :D > Wiring PI / Arduino hat schon seine Berechtigung. Es ist Lego in > Software. Sicher ein schöne Sache für Einsteiger, aber irgendwann ist > halt mal Schluss. Dieses "irgendwann" hat mich früher erwischt als befürchtet. > Das kommt noch dazu. Ich kenne zwar die Architektur vom Linux als auch > vom Wiring nicht im Detail, aber ich ahne Schlimmes. Da wird selbst das Ich glaube, es ist NOCH schlimmer :) > Alles wird gut. Erst recht mit einem AVR ;-) Das denke ich auch, weswegen ich mich jetzt erst mal darauf konzentriere. Danke, 42m
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.