Ich möchte gerne Fehler beim Posten vermeiden, und aus gemachten zumindest lernen.
Nur weiss ich nicht, was falsch an meiner Frage war.
Die Aufgabe war doch klar: Impulse zählen zur Länegnmessung. Und die mir zugänglichen Werkzeuge waren genannt.
Was also war falsch?
Ausser, das ich mir das Posting hätte sparen können, wenn ich gleich gerechnet und nicht gefühlt hätte. Siehe weiter unten im Thread.
Viele Grüße, Rolf
Hallo David!
Hast recht, geht also in Software.
Ganz lieb von Dir, steht aber in der FAQ.
Vielen Dank und viele Grüße, Rolf
Hut ab!
Habe ich ich wieder. Die eigentliche Interruptroutine ist jetzt 102 Zyklen lang und fast fertig. Geht wirklich locker!
Das Gleiche aus dem sonnigen Petershagen! ;-)
Rolf
An der Frage war nichts Falsch, die war gut formuliert. Das Problem gut geschildert, die Aufgabe klar dargestellt, ...
Nur das Subject suggerierte, dass Du auf eine bestimmte Microcontroller Plattform vorab festgelegt bist. Viele Fragen, nicht nur in dieser Newsgroup (meines empfindens momentan überall in Deutschland), schreiben den Lösungsweg oder ein Werkzeug (Hard- oder Software) vor und dann soll man damit die Aufgabe lösen, obwohl es bei weitem billigere und effizientere Wege gäbe. Das stösst mir immer etwas auf.
(Beispiele:
- Festlegung auf ein Betriebssytem, ohne Rücksicht auf den Einsatzzweck, siehe Schaltungs-Software-Thread.
- Windows in harten Echtzeitumgebungen
- Windows CE Touchscreen Bedienteile, die schön bunt, aber fast unbedienbar langsam sind, Microcontroller und einzeiliges Textdisplay waere Anwenderfreundlicher.
- die Liste liesse sich endlos fortsetzen)
Einige schreiben zum Teil sogar nur das Werkzeug vor und vergessen die Beschriebung der Aufgabe.
Aber wie ich schon geschrieben hatte, nach dem Subject hat mich der Inhalt positiv überrascht.
Gute Nacht
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 ^`~'^
Da sich die Frage eher nach Hobbyprojekt als nach einer Großserie anhörte kann das durchaus Sinn machen. Als Hobbyist arbeitet man sich nicht unbedingt in eine neue Mikrokontroller-Umgebung ein nur weil der PIC mit dem Quadratur-Eingang 1 Euro billiger ist als der entsprechende AVR. Man nimmt die Teile und Methoden mit denen man sich auskennt und schaut wie man damit hinkommt, auch wenns etwas umständlicher wird. Schon wegen der Zeitersparnis. Im schlimmsten Fall entscheidet der Inhalt der Bastelkiste über die Bauteilauswahl (in meinem Fall ein Mega8 zum Dekodieren einer IR-Fernsteuerung -> hoffnungslos überdimensioniert, aber extra einen kleineren bestellen? Ist ja schon wegen der Versand- kosten ein Minusgeschäft.)
Georg
-- Die Reply-To Adresse ist reply-fähig ;-)
Aber einen muss ich noch drauf setzten, auch wenn ich meinen Denkfehler einsehe. Mit _einem_ Int-Pin wirds nix, klar.
Aber wenn _zwei_ Pins Int-fähig sind kann ich doch ganz leicht die State-Machine auch dort implementieren. Muss mir nur die Zustände des jeweils anderen Pins mit merken....
Und WENN Prellen kommt dann halt einfach ignorieren, weils ja noch der alte Zustand ist. Schnelles prellen müsste sowieso wegzubekommen sein, weil ja der selbe Interrupt nicht sofort wieder auslöst...
Oder mach ich da schon wieder einen Denkfehler?
Heinz
Hallo,
Wichtig ist halt, dass man _beide_ Flanken des Signals auswertet, nicht dass man zwei Int.-Pins hat.
Aber: Angenommen, das Teil stehe auf der Kippe. Es gäbe einen kurzen Impuls ab, überlegt es sich aber anders. Dann würde mit Impulsbeginn ein Int. angefordert werden, während das Ende verschluckt würde.
Je nach Architektur, sicher jedoch bei der vier Pin-Lösung, würde die zweite Anforderung warten, bis die erste abgearbeitet ist.
Wenn man zwei Pins hat, die jeweils auf beide Flanken reagieren (oder mit vier Pins und passender Programmierung/Beschaltung, wenn das nicht geht), kann man die Auflösung verdoppeln.
Aber selbst dann kann, wenn das Ding auf Kippe steht, die Int.-Last sehr hoch werden.
Ich habe es mal so implementiert auf einer C166-Architektur. Da kann man einen Pin auf beiden Flanken /einen/ Int. anfordern lassen. Der beschriebene Fall ("Je nach Architektur...") macht keine Probleme, da die Interrupts nicht wirklich flankengetriggert angefordert werden, sondern eine State-Machine in der Interrupt-Logik ihrerseits die Zustände der Pins alle 16 (?) Systemtakte abfragt.
Ansonsten war es ein optischer Encoder an Schmitt-Trigger-Eingängen, der prellt halt nicht. Problematisch war nur die Abfrage des jeweils anderen, keinen Int. anfordernden Signals, da dieses erst in der Routine, also nicht zum Zeitpunkt der anfordernden Flanke erfolgt. Allerdings war der Encoder "nur" für Benutzer-Eingaben zuständig, da ist ein gewisser Schlupf normalerweise tolerierbar. Im Übrigen habe ich auch bei extremeren Bewegungen keinen Schlupf gefühlt (d. h. nicht, dass es nachgemessen hätte).
HTH - Peter
-- Für Privat-Email bitte Betreff mit "Usenet-Reh" beginnen lassen. -- "Ein Mokka-Trüffel-Parfait mit einem Zitronencreme-Bällchen."
Nachtrag:
Problem meiner Implementierung war, dass bei sehr schnellen Bewegungen der Zähler aus dem Tritt kommen kann, was bei der Anwendung nicht praxisrelevant war.
Wertet man jedoch nur eine Flanke aus, kann man auch durch beliebig langsames Hin- und Herdrehen an der richtigen Stelle den Zähler immer weiter zählen lassen
Guten Abend
-- Für Privat-Email bitte Betreff mit "Usenet-Reh" beginnen lassen. -- "Ein Mokka-Trüffel-Parfait mit einem Zitronencreme-Bällchen."
ich könnte mir vorstellen, dass das auch geht ... wenn man für beide Pins und beide Flanken einen Interrupt erzeugen kann
Vorteil: die mittlere Systemlast sinkt deutlich
- Bei Ruhe: gar keine Rechenleistung nötig
- bei voller Drehgeschwindigkeit hat man etwa die Last wie beim Einsatz des Timer-interrupts
- wenns prellt bekommt man im worst case kurzfristig 100% Last
Die Auswertung bleibt aber trotzdem zustandsgesteuert!
bye, Michael
"Peter Muthesius" schrieb im Newsbeitrag news:4329d694$0$18640$ snipped-for-privacy@news.sunsite.dk...
Ohh je. Was eine handoll TTL ICs spielend bis in den MHz Bereich machen kann wird hier mit biegen und brechen in Software gestopft. Muss (und will) ich nicht verstehen.
Schmitt-Trigger-Eingängen, der
Falsch. Der kann auch prellen. Es sei denn man hat einen richtig dimensionierten RC-Filter davor.
kt der anfordernden Flanke erfolgt.
Aha, sowas wie gefühlte Temperaturen. Naja.
MfG Falk
P.S. Warum wollen alle Lete das Fahrad neu erfinden und bauen dabei 4eckige Räder dran??
P.P.S. Um auf die Ursprungsfrage zu antworten.
a) "hippe" Lösung. kleiner CPLD mit 32 Macrozellen, z.B. Coolrunner oder XC9500XL b) "classic" eine Handvoll TTL Gatter, da kann man sein Talent für Logikoptimierung (Karnaught & Co) beweisen
Hallo,
Bitte erläutere das näher.
Ich verstehe nicht, warum man nicht eine SW-Lösung machen soll, wenn man keine Megahertze braucht.
Gute Nacht - Peter
-- Für Privat-Email bitte Betreff mit "Usenet-Reh" beginnen lassen. -- "Ein Mokka-Trüffel-Parfait mit einem Zitronencreme-Bällchen."
"Falk Brunner" schrieb:
Sicher dafür eine schöne Übung, ansonsten x-facher Leistungs- und Platzverbrauch gegenüber dem Controller.
-- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
"Peter Muthesius" schrieb im Newsbeitrag news:4329ea5f$0$18646$ snipped-for-privacy@news.sunsite.dk...
Nun, was ist denn Prellen? Hier beim Inkrementalgeber bedeutet das, dass ein Kanal sehr schnell seinen Zustand wechselt, wesentlich schneller als bei maximaler Drehzahl (Pulszahl). Auf diese kurzen Impulse reagiert natürlich auch der Schmitt-trigger (wieso auch nicht?). Erst ein RC-Filter vor dem Schmitt-trigger filtert die sehr kurzen Pulse weg.
Nun ja, der OP sprach von 20 kHz Pulsfrequenz. Macht 50us. Bei 10 MHz CPU-takt sind das gerade mal 500 Takte. Nimmt man dann noch einen Faktor 2-4 für die Überabtastung dazu sinds nur noch 125 Takte. Für die reine Quadraturdekodierung reichts vielleicht. aber er will ja noch die Anzeige machen, das wird dann schon kniffelig.
Machbar (mit ner gehörigen Portion KnowHow oder oversized CPU) aber nicht unbedingt meine Empfehlung. Ausserdem hatten wir ja vor kurzem das Problem dass ein Controller mal so fix nebenher inen Inkrementalgeber auswerten sollte. Schön schnell, 100%OK aber ohne Rechenpower. Naja.
MfG Falk
"Joerg Wunsch" schrieb im Newsbeitrag news:dgdjt4$vh2$ snipped-for-privacy@uriah.heep.sax.de...
Schon klar, deshalb auch "classic". Und wer keine Erfahrung mit Controllern hat, kann das vielleicht eher hinkriegen.
MfG Falk
Peter Muthesius schrieb:
Die neuen ATMegas haben doch einen Pin-Change-Interrupt: Eine beliebige Flanke an bis zu 8 maskierbaren I/O-Pins löst einen Interrupt aus. Ist doch ideal für diese Anwendung.
Gruß Henning
-- henning paul home: http://www.geocities.com/hennichodernich PM: henningpaul@gmx.de , ICQ: 111044613
"Falk Brunner" schrieb:
Faktor 2-4
Anzeige
Auch auf die Gefahr hin, etwas zuviel zu versprechen: Nach meiner Einschätzung reicht für den Zweck Impulszählung und multigeplexte Anzeige auch ein tiny2313. Auch eine Übersprungsdetektion zur Warnung vor "Verzählern" dürfte noch problemlos machbar sein.
Die Lösung besteht dann im Wesentlichen aus einem 20-Pinner, einem Quarz, fünf 7-Segment-Ziffern nebst Widerständen und ein paar KerKos. Schätze mal ein, wieviele TTL-Käfer kann man verbauen (und wie gross, und kostet wieviel), um denselben Zweck zu erreichen?
-- Es gibt keine Neue Rechtschreibung. Es gibt eine Rechtschreibung und eine neue Schreibweise. Ausserdem hätte ich lieber eine Mathematikreform, dann wäre das Rechnen nicht so schwer.
"Andreas Donner" schrieb im Newsbeitrag news:dgf27m$1o6g$ snipped-for-privacy@ulysses.news.tiscali.de...
Einen 16 Bit Zählerstand auf ein paar 7Segmentanzeigen zu MUXen ist kein Akt, da langweilt sich der Controller zu Tode. Aber mit 80 KHz die Quadraturimpulse zu sampeln UND nebenbei die Anzeige MUXEN wird schon ne kleine bis mittlere Herausforderung. Nicht vergessen, du musst noch von binär in dezimal umrechnen, oder gleich in BCD zählen, was auch mit einem gewissen (Zeit)aufwand verbunden ist.
Hardware soweit klar. Der Knackpunkt ist die Software. Mach mal, wir werden dann mal sehen.
Ich hab nie behauptet, dass das TTL-Grab kleiner und billiger ist. Es ist jedoch für die Microcontroller-unerfahrenen (ja gibts denn sowas heute noch ? ;-) einfacher aufzubauen (Idee vom OP, Einfach Dekoder + Vorwärts/Rückwärtszähler + Reset).
Ich würde prinzipiell auch gern beweisen, dass es mit nem kleinen 20pin AVR geht. Records are made to be broken!
Also, wer macht mit?
MfG Falk
Hallo,
Also, Du meinst nicht das Prellen mechanischer Kontakte, welches natürlich auch bei mechanischen Kontakten in Encodern auftritt. (Zumal ich ja von optischen Encodern sprach.)
Warum sollte ein Kanal schnell seinen Zustand wechseln? Wenn er schnell hin- und herbewegt wird? Wenn Störungen auf den Signalleitungen sind? Ich verstehe nicht, was Falk meint.
Die Anzeige muss ja nicht 80 kmal je Sekunde aktualisiert werden. Dekodierung im Timer-Int., Rest dazwischen.
Gute Nacht - Peter
-- Für Privat-Email bitte Betreff mit "Usenet-Reh" beginnen lassen. -- "Ein Mokka-Trüffel-Parfait mit einem Zitronencreme-Bällchen."
"Falk Brunner" schrieb:
werden
Fertig. Jetzt hab ich's halt doch mal probieren müssen. AT90S2313 mit
16MHz. Abtastung, Dekodierung und Übersprungdetektion in einer 50µs-Task, das reicht grenzwertig für 20kHz. Aufdröselung des Anzeigezählers in 5 Ziffern plus Vorzeichen und Multiplexen der Anzeige in der Hauptschleife. Warnung bei Übersprung und Bereichsübertretung durch Anzeige mit abwechselnd blinkendem Zahlenwert und Strichen "-----". Rückstellung der Einfachheit halber durch Reset. Belegung ist 71% von 2kB. Kein Pin mehr übrig ;-)
-- Es gibt keine Neue Rechtschreibung. Es gibt eine Rechtschreibung und eine neue Schreibweise. Ausserdem hätte ich lieber eine Mathematikreform, dann wäre das Rechnen nicht so schwer.
"Peter Muthesius" schrieb im Newsbeitrag news:432c9ab8$0$18648$ snipped-for-privacy@news.sunsite.dk...
Tach auch,
Auch optische können prellen. Das ist dann zwar ein etwas anderer Wirkmechanismus, aber das Ergebnis ist praktisch gleich. Stell dir vor, der Encoder bleibt genau "auf der Kippe" stehen und die Welle vibriert ein wenig. Schwupps, schon prellts.
Siehe oben.
Soweit die (unvollständige) Theorie. Schon klar, deine MUX-Routine muss nur sagen wir mal 500 mal pro Sekunde laufen (5 Stellen mit 100 Hz geMUXt). Aber während deine MUX Routine läuft muss die Abtastung weiter laufen. Und das wird kniffelig.
MfG Falk
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.