AVR oder TTL f. Laengenanzeige?

es sollte 100/Pulse/Millimeter heißen.

Rolf

Hm..noe. Ich hab einen Mega8 der steuert einen Motor mit so einem Wegzaehler. Ich hab das nur bis 12.5kHz ausgelegt, aber ich hab zusaetzlich noch einen Kaskadenregler fuer Geschwindigkeit und Position laufen ausserdem wird die Position noch auf einem LCD ausgeben und bei der RS232 nach Kommandos geschaut.

Ich seh da eigentlich keine Probleme wenn du nur die Position anzeigen willst. Klar der IRQ laeuft oft, aber dafuer ist er sehr kurz.

Wahrscheinlich nicht weil du dir dann Gedanken um das 'entprellen' machen musst. Ausserdem kann der AVR auch noch gleich das Multiplex fuer die Anzeigen machen.

Olaf

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....

Es gibt Motor Control Microcontroller mit passenden Encoder-Interface, die die Position in Hardware zählen und das auch noch im MHz-Bereich.

Atmel scheint noch nichts entsprechendes anzubieten, aber diverse andere. Microchip. z.B. mit dem dsPIC30F2010 und anderen.

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
 ^`~'^

Quadratur encoder? Die haben die wundervolle eigenschaft, dass man sie direkt mit einem up/down Zaehler verbinden kann. Und zwar den ersten Ausgang and den Takt und den zweiten Ausgang an die Zaehlrichtung. Einzige Voraussetzung ist, dass der Zehler bei ansteigender oder abfallender Flanke zaehlt (machen aber im Prinzip alle).

Die Loesung is also simpel: jeder up/down Zaehler funktioniert. Die gibts als binaer oder dezimal zaehler, mit binaer oder 7-Segment ausgang, lasssen sich auf beliebig viele Stellen erweitern, etc. etc. . Einfach mal unter den 74... standard TTL Chips suchen.

Hallo Rolf!

Ich nehme an, dieser inkrementalgeber funktioniert nacht dem Quadratur-Encoder prinzip oder? 2 Phasen, 90=B0 verschoben? Da hab ich n=E4mlich auch schon was programmiert und hatte wirklich keine Probleme, war auch Interrupt gesteuert. Meiner Meinung nach m=FCsste es mit einem Atmega8 und 16MHz taktfrequenz kein problem sein, auch jenseits von

20KHz zu samplen. Also ich pers=F6nlich w=FCrde es Softwarem=E4ssig versuchen. Mit TTL-Bausteinen wird es da schon viel komplizierter, als mit Software... k=F6nnte mich sonst auch noch umschauen wegen dem algorithmus.

gruss und gute nacht!

-- mailto: david_greminger (at) bernina.com

Hallo NG,

Bitte in der Faq nachschauen, warum dieses Vorgehen ungünstig ist.

Gute Nacht - Peter

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

Hallo Rolf,

Geht schon, wie andere bereits schrieben.

Wenn Du nicht viel Erfahrung mit uC hast, fuehrt das sicher schneller ans Ziel. Am besten CMOS Series, entweder CD4000er oder bei unter 6V eben 74HC. Wenn Du schon viel uC gemacht hast, wuerde ich auch einen solchen nehmen.

Gruesse, Joerg

dein Timer-Interrupt sollte also mindestens mit 20 kHz laufen ... bei 16 MHz Controllertakt sind das etwa 800 Takte

Schaun wir mal den zustandsgesteuerten Decoder an (Genaue Beschreibung steht in der FAQ) - im Prinzip ist es eine wirklich primitive Zustandsmaschine a la

neuer_Zustand = Tabelle[alter_Zustand][PinA][PinB] und in manchen Fällen noch ein Counter increment/decrement (es gibt nur 4 verschiedene Zustände, PinA und PinB sind je 1 bit, macht zusammen 16 Einträge in der Tabelle)

also wenn man das nicht in 800 Takte reinbekommt, dann hat man wohl die falsche Programmiersprache oder das Problem nicht verstanden ...

und falls es noch nicht deutlich genug war: Auswertung mit Flanken und Interrupts von den Pins sind allgemein keine gute Lösung - Zustandsauswertung ist nicht aufwändiger und sicher. Details siehe letzte Diskussion (google)

bye, Michael

Hallo Daniel!

Was sonst hättest du unter dem Topic "AVR oder TTL f. Laengenanzeige?" erwartet?

Das wäre für 20 kHz wohl mit Kanonen auf Spatzen geschossen. Zumal man entsprechende Schaltungen wohl auch kaum bei Conrad oder Reichelt bekommt. Man könnte es auch in einem FPGA implementieren, aber auch das wäre zu kompliziert und damit für den OP kaum hilfreich...

Gruß Thorsten

--
PGP welcome!
Thorsten online: http://www.ostermann-net.de/electronic
Rund um Schrittmotor, Fräs-Bohr-Plotter & Mikrocontroller

Rolf Bredemeier schrieb:

Nein, gar nicht. 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.

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

Willst Du Dir das wirklich antun? Ein Atmel kostet keine drei Euronen. Damit steckst Du Deine Schaltung zusammen und dann musst Du nur noch programmieren und nix mehr löten.

Und "ich brauche nur" kenne ich von Kunden zu genüge. Glaube mir: es kommt irgendwann *immer* noch ein "schön wäre auch" ;-) Dann ist es gut, Reserven zu haben und flexibel zu sein. Deswegen ->

Controller

Eben: teuerer, größer, energiefressender, unflexibel, fehleranfällig. Mein Tipp: Lass es.

Keine Ursache :-)

Viele Grüße aus der Vulkaneifel, Christoph

--
Electronic Thingks - Christoph Drube - www.electronic-thingks.de
Entwicklung und Vertrieb von Systemsoftware und Hardwarekomponenten,
Bausätze, Mikrocontroller, hardwarenahe Programmierung in C, C++ und
Tcl/Tk, Infos/Material zum Eloxieren, Linux-Netzwerke, WWW-Entwicklung

hmm. Quadratur-Signal nehme ich an...

+---+ +---+ +---+ +---+ "CLK" | | | | | | | | +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ "DIR" | | | | | | | +---+ +---+ +---+ +---+

eines als Takt, eines als Richtungssignal...

Warum nicht den Takt an einen INTR-fähigen Pin legen?

Und in der SW dann einfach den zweiten Pin abfragen und entsprechend einen SW-Zähler +/- eins zählen. Die Intr-Routine ist so nur wenige Bytes lang. Und im "Hauptprogramm" den ganzen anderen Schrümmel erledigen.

Das sollte sich mit fast jeder CPU erledigen lassen.

Heinz

schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Weil man das genau so ganz ganz bestimmt nie machen sollte ? Siehe de.sci.electronics FAQ:

F.29. Quadraturdecoder für Inkrementaldrehgeber

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Hallo,

Und warum? Als Abschreckung ist mir noch der Thread ab news: snipped-for-privacy@individual.net von Gerald Oppen am 13 Jul. 19:19 in Erinnerung. Leider kann ich ihn nicht bei Groople anzeigen lassen.

Ciao - Peter

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

alle 3 Wochen das gleiche ... das ist nur der günstigste Fall konstanter Geschwindigkeit. Wenn dein Geber auf der Kante steht, dann gibts sowas

+---+ ++++-------+ +---+ +---+ "A" | | |||| | | | | | +---+ +-------++++ +---+ +---+ +---+ +---+ +---+ +---+ "B" | | | | | | | +---+ +------------------+ +---+ +---+

Flankenwechsel koennen beliebig schnell werde -> man kann nie alle mit einem Interrupt-Eingang erfassen

was tun? wenn man genau hinschaut sieht man, dass diese schnellen Wechsel keiner echten Bewegung entsprechen -> man braucht sie nicht erfassen - die Auswertung darf nur nicht durcheinanderkommen

Eine *zustandsgesteuerte* Auswertung kommt damit klar, die würde man im Timerinterrupt machen und ist auch ziehmlich kurz. (siehe FAQ)

ack

bye, Michael

"Peter Muthesius" schrieb im Newsbeitrag news:43284374$0$18641$ snipped-for-privacy@news.sunsite.dk...

Steht in dem direkt darunterstehendem Link dem du nur mal haettest folgen muessen.

Klappt problemlos, lass news: bei der Nachrichten-ID weg.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Hallo,

Schon klar; war 'ne rhetorische Frage.

Das Posting sehe ich schon, aber wenn ich den Thread anzeigen lassen will, beginnt er immer mit einer Antwort von Dir:

:(

Den Beginn habe ich erst aus den References-Headern extrahieren müssen.

Ciao - Peter - dem Groups-Google-Nicht-Beta hinterhertrauernd

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

*grmpf*erwischt*schäm* stimmt, da war ein Thread vor einiger Zeit..... *kopfkratz*

Heinz

Ich sehe, Du hast Dir den Prozessor oder andere Alternativen mal angeschaut.... ... der genannte Prozessor liegt bei ca. 7 EUR, hat digitale Filter für das Quadratur-Signal, ist schnell beim Zählen und erledigt alles andere, was gefordert ist auch.

Wenn die 3,50 EUR mehr im Vergleich zu nem Mega16 für deutlich weniger Stress bei der Entzwicklung sorgen, dann nenn ich das höchstens ein "Kanönchen".

Ich nutze auch den AVR gerne, aber hier würde ich eindeutig den dsPIC bevorzugen, jeder Prozessor hat halt seine Vor/Nachteile, weshalb ich die Vorauswahl im Subject kritisiert hatte.

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
 ^`~'^

Du hast komplett und völlig recht. Ich habe gerade das Hoch-Runterzählen mittels State-Machine, wie von in der Faq beschrieben, implementiert. Gibt bisher 102 Zyklen. und der Rest kann natürlich außerhalb des INT laufen.

Mein Fehler war, ich habe nicht gerechnet, sondern nur "gefühlt", das 20KHz knapp werden.

Ich werde in Zukunft erst nachrechnen. In 50uSec lässt sich wirklich eine Menge erledigen.

Werds mir merken, Danke für den Zeigefinger!

Viele Grüße, Rolf