Verzeiht mir wenn ich jetzt mal kräftig in den Fettnapf trete. Vor Jahren adoptierte ich die in C geschriebenen Drehgeber Routinen vom Peter auf allen möglichen uC und haben bei mir ohne Ausnahme mit minimalsten Schwierigkeiten überall einwandfrei funktioniert. Hier die Liste: PIC18F8722, PIC18F4620, PIC30F6014, PIC33Mc510, AVR, 8051, CORTEX M3/4, ZILOG Encore! Außer Hardware notwendigen Anpassungen gab es nichts zu ändern oder daran rütteln. Ich habe sowohl verschiedene mechanische neben einigen optischen Drehgebern getestet. Kontaktprellprobleme gibt es auch bei einer ISR Wiederholungsrate von 1ms nicht. Man kann sogar ohne wesentlichen Zählfehler ziemlich schnell daran drehen. Ich würde also deshalb vorschlagen sein Beispiel zuerst zum Laufen zu kriegen, weil es mit absoluter Sicherheit funktionsfähiger Code ist und die Mühe auf alle Fälle wert ist. Sein Beispiel kann man als De-Fakto Referenzdesign schlechthin ansehen. Ich kann es nur wärmstens empfehlen und ist wirklich kein Jägerlatein;-) Mfg, Gerhard
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_4815.JPG
74 KB -
IMG_4811.JPG
360 KB
Volker S. schrieb: > Versprochenes Beispiel eines Signalverlaufs Panasonic EVEQ mit 32 > Rastpunkten (20 ms/Div) Axel S. schrieb: > Ich bin fest davon überzeugt, daß das gezeigte Verhalten ein Artefakt > der Meßmethode ist. Hallo zusammen, mir hat dieses Signal und die Frage, ob das einfach ein Artefakt ist, keine Ruhe gelassen. Deshalb habe ich mal den billigen Pollin-Drehgeber EVEQDBRL416B in meine Bohrfräsmaschine eingespannt - in diesem Drehzahlbereich ist sie zwar nicht wahnsinnig Drehzahlkonstant, aber für eine Abschätzung sollte es reichen. Da ich keine Screenshots machen kann, hier nur ein einfaches Bildschirmfoto vom Oszilloskop. Der Effekt, daß das Puls-Pausen-Verhältnis nicht ganz 50% ist, kann man erkennen, und der Phasenversatz ist auch nicht exakt bei 90°. Aber so stark, wie bei der Messung von Volker S. ist das auch alles nicht von diesem Idealbild (50%/90°) entfernt. Ich nehme also auch an, daß der Unterschied dort durch den Ruck in den Rastpunkten kommt. Auch meine Q&D-Einspannung ist nicht wahnsinnig steif. Und für einen 75-Cent-Drehgeber sind die Toleranzen sogar ziemlich gut. Für mich bleibt die Erkenntnis: Bei einem Drehgeber, der von Hand betätigt wird, können riesige Sprünge in der Winkelgeschwindigkeit auftreten. Also sollte man bei einer Abschätzung einer sinnvollen Abtastrate mehr auf die mit dem Oszilloskop gemessene minimale Pulsbreite als auf Annahmen, wie schnell ein Mensch drehen kann, verlassen. Viele Grüße W.T.
Gerhard O. schrieb: > Außer Hardware notwendigen Anpassungen gab es nichts zu ändern oder > daran rütteln. Ich möchte das auch unterschreiben - ja, auch ich habe früher mal einen PC- oder ext. Int für den Drehgeber genommen, bin aber durch die Robustheit von PeDas Routinen davon völlig abgekommen. Der Timer fragt bei mir nicht nur den Drehgeber ab, sondern auch alle 10 mal etwaige Taster, so das dieser eine Interrupt für alle Benutzerabfragen sorgt, klein kompakt und schnell. In den meisten Projekten bei mir gibt es sowieso Bedarf für einen Ticker. Mich beeindruckt dabei besonders, das die Routine auch mit den ollsten prellendsten Drehgebern klarkommt, die ich hier habe. Das ich zwischen Drehgeber und MC noch ein paar Bauelemente plaziere, wie R und C, liegt daran, das ich nur ungerne direkt Portleitungen an Benutzerelemente führe.
Walter T. schrieb: > Hallo zusammen, > > mir hat dieses Signal und die Frage, ob das einfach ein Artefakt ist, > keine Ruhe gelassen. Deshalb habe ich mal den billigen Pollin-Drehgeber > EVEQDBRL416B in meine Bohrfräsmaschine eingespannt Also dann zum Drehgeber immer gleich eine Bohrfräsmaschine mitliefern, damit der Benutzer auch "richtig" drehen kann oder was ? Ihr seid mir schon'n paar feine Theoretiker. Bestimmt von der Uni ;-)
vloki schrieb: > Ihr seid mir schon'n paar feine Theoretiker. Bestimmt von der Uni ;-) Äääähhh, bitte nicht zu ernst nehmen. Ich dachte nur gerade an die Uni vs. FH Battles ...
Eventuell ist es beim manuellen Durchblättern eins Menüs ja auch kein Problem, wenn wegen nichtkonstanter Winkelgeschwindigkeit ein Dreh untergeht. Wir reden ja nicht von Absolutwertpositionsmessung im 2..3-stelligen kHz Bereich, sondern von günstigen Eingabe-Bauteilen und wenn man mal schnell 10 Menüpunkte rauf oder runter muß, dann bleibt man im 2-stelligen Herz Bereich. Und das Ganze in einen "Regelkreis" über visuelle (LCD-)Rückmeldung.
vloki schrieb: > bitte nicht zu ernst nehmen Wer 90° bzw. 50% erwartet, muss halt ordentlich Hornhaut auf seinen Fingern haben und kräftig zupacken. Mit zarten Frauenhänden, die den Knopf wie ein rohes Ei anfassen, sieht das Diagramm so aus, wie in screenshot27.png. ;-)
vloki schrieb: > Also dann zum Drehgeber immer gleich eine Bohrfräsmaschine mitliefern, > damit der Benutzer auch "richtig" drehen kann oder was ? Dich interessiert also nicht, welcher Effekt durch den Drehgeber und welcher durch den Nutzer kommt? Mich schon. Aber vielleicht liegt es daran, daß ich tatsächlich von der Uni bin. Viele Grüße W.T. -- Dr. Walter Tarpan Lehrstuhl für Bedienelementesinologie TU Osnabrück
Gerhard O. schrieb: > Vor Jahren adoptierte ich die in C geschriebenen Drehgeber Routinen vom > Peter auf allen möglichen uC und haben bei mir ohne Ausnahme mit > minimalsten Schwierigkeiten überall einwandfrei funktioniert. Hier die > Liste: > > PIC18F8722, PIC18F4620, PIC30F6014, PIC33Mc510, AVR, 8051, CORTEX M3/4, > ZILOG Encore! Dito in PSoC4 (M0). Auch im Multiplexbetrieb (4Drehgeber) no Problem mit Peters Routine. Einzige Änderung: Ich zähle nur die Rasten, statt der Stati, da bleibt der Counterbereich konstant, weil nicht je nach Rastenanzahl dividiert werden muss: Auszug:
1 | if (0 == slast % (1 << encoderMode){ // only the right state 0,1,2->1,2,4
|
2 | counterValue += (s & 2) - 1; |
3 | } |
Mit encoderMode = 4 * pulse / detent Achso, natürlich ohne sonstirgendwelche Entprellung
:
Bearbeitet durch User
Mal zwei Fragen an die Flankeninterrupt-Fraktion: 1) Schaltet Ihr die Flanken-Interrups in der ISR immer zwischen steigend und fallend um? Oder reagiert der Interrupt immer auf beide Flanken und wertet Ihr dann den Pegel in der ISR aus? Volker S. schrieb im Beitrag "Re: Drehimpulsgeber" > Es gibt mindestens zwei unterschiedliche Konzepte. Bezogen auf das rechte Diagramm in 'screenshot25.png', wo das Signal B im Rastpunkt unbestimmt ist: 2) Macht Ihr den Flankeninterrupt nur bei Signal A oder auch bei Signal B?
:
Bearbeitet durch User
Walter T. schrieb: > Dr. Walter Tarpan > Lehrstuhl für Bedienelementesinologie > TU Osnabrück Ohne zu suchen: ist das jetzt real? Das würde immerhin erklären, warum Du Dir (zu Recht) die besseren Bourns leistest ;-) Torsten C. schrieb: > Oder reagiert der Interrupt immer auf beide Flanken > und wertet Ihr dann den Pegel in der ISR aus? So ist es einfacher. Beim AVR können INT0 und INT1 bei jeder Flanke die ISR auslösen; ebenso auch der PCINT. Torsten C. schrieb: > 2) Macht Ihr den Flankeninterrupt nur bei Signal A > oder auch bei Signal B? Nur eine Phase gibt 2-fach, und beiden Phasen ergeben 4-fach Auswertung. Sofern man nicht höchste Auflösung braucht, reicht es, nur eine Phase auszuwerten. probiere doch mal dieses Beispiel: volatile int32_t count; #define PHASE_A 2 // INT0 #define PHASE_B 3 // INT1 löst hier aber keine ISR aus #define MASKE (BIT(PHASE_A)+BIT(PHASE_B)) ISR(INT0_vect) { int8_t temp; temp = PIND; // nur ein einziger Zugriff auf PIND ! if((temp & MASKE) == MASKE || (temp & MASKE) == 0) temp = 1; else temp = -1; count += temp; // verkürzt den Code } Matthias S. schrieb: > ja, auch ich habe früher mal einen > PC- oder ext. Int für den Drehgeber genommen, Bei mir ist es genau anders: vor 30 Jahren habe ich fleißig gepollt, da nichts Anderes möglich war; wenn es schnelle Signale waren, mußte ext. Hardware ergänzt werden. Bei den neueren µCs hat man aber erheblich bessere Leistung (Flankenerkennung + Schnelligkeit), sodaß ein Interrupt deutlich eleganter zu benutzen ist, auch wenn viele aus alten Erfahrungen richtige Angst vor Interrupts haben und sich davon auch nicht befreien wollen/können.
Torsten C. schrieb:
>Mal zwei Fragen an die Flankeninterrupt-Fraktion:
Also meine Überlegungen waren bisher nur Theoretisch.
Ich würde den Interrupt auf alle Flanken, bei beiden
Kontakten reagieren lassen, und dann die Pegel in
der ISR auswerten. Wozu hat der Hersteller die
Flankeninterruptfunktion mit eingebaut, wenn man
sie nicht benutzen darf, nur für die Dümmsten?
Praktisch habe ich es aber noch nicht ausprobiert.
Werde ich aber mal in 4 Wochen, wenn ich mehr Zeit habe
mit einem 80C31 mal machen. Ich werde alle Varianten
die hier Vorgeschlagen wurden auf ein Steckbrett mal
testen und Beobachten was passiert. Ich bin kein
Ingenieur und auch kein Dr. Ich befasse mich mit diesen
Dingen nur Hobbymäßig.
Angehängte Dateien:
-
Drehgeber.png
70 KB
Günter Lenz schrieb: > Ich würde den Interrupt auf alle Flanken, bei beiden > Kontakten reagieren lassen, und dann die Pegel in > der ISR auswerten. Naja, sicher ne gute Programmierübung. (siehe Bild) War (glaube ich) der Alps 12.
m.n. schrieb: > probiere doch mal dieses Beispiel: Probieren ist blöd, nachdenken besser: Nehmen wir mal einen realen prellenden Kontakt http://mezdata.de/isp/080_entprellen-mit-ff/ Mal ein paar angenommene Zeiten: 1us an falsch erkannt 0 5us aus verpasst 10us an +1 10us aus -1 7us an +1 100us aus verpasst 7us an +1 25us aus verpasst 10us an +1 50us aus -1 100us an +1 25us aus -1 1us an falsch erkannt 0 5us aus verpasst 20us an +1 20us aus -1 7us an +1 50us aus verpasst ewig an Summe: +3 Die Interrupt-Routine braucht 9us, nach 2us erfasst sie die Ports während der Interrupt bedient wird, sind andere Interrupts gesperrt. Der eine Kontaktwechsel löst also 13 Interrupts aus, die +3 zählen. Ohne extra Hardware aus RC Glied und Schmitt-Trigger, die die Impulszeit garantiert auf die maximale InterruptDauer ausdehnen, https://www.mikrocontroller.net/articles/Datei:Entprellung_mit_IIR-Filter.gif funktioniert die Erfassung nicht zuverlässig. Und ob und wann ein Taster wie schnell prellt, unterliegt einer Menge Randbedingungen, Staub und Oxid, Vibrationen und Alterung, das einzige, was der Hersteller garantiert, ist, daß z.B. nach 5ms das Prellen bestimmt vorbei ist. Wenn also ein Drehgeber beim Ausprobieren funktioniert, ist das mit dieser falschen Auswertung noch lange keine Garantie dafür, daß er am Freitag immer noch fehlerfrei läuft.
m.n. schrieb: > Das würde immerhin erklären, warum Du Dir (zu Recht) die besseren Bourns > leistest Die optischen Bourns-Drehgeber sind das, was früher 10-Gang-Potis waren: Bedienelemente für eine sehr feinfühlige Bedienung. Gern auch für Drehknöpfe mit größerem Durchmesser. Beispiel: CNC-Handrad, Frequenzwahlknopf an besseren Funkgeräten ... (Und, O.T., aber interessante Parallele: Als Meßaufnehmer z.B. für Plotter waren die 10-Gang-Potis auch recht beliebt.) Eine Menüsteuerung würde ich nur im Notfall damit machen. Die feine Einteilung müßte ich für eine sinnvolle Menü-Bedienbarkeit massiv herunterteilen und die fehlenden Rasten stören da auch. Für Menüs sind die billigen Drehgeber mit 32 Rastungen und eingebautem Taster wunderbar. Vermutlich hat damals auch kaum jemand ein Radio mit 10-Gang-Lautstärkepoti entwickelt ... Deswegen habe ich auch beide Typen in der Bastelkiste und beide werden für ihren Zweck eingesetzt.
:
Bearbeitet durch User
Günter Lenz schrieb: > Werde ich aber mal in 4 Wochen, wenn ich mehr Zeit habe > mit einem 80C31 mal machen. Der 8051 in ursprünglicher Form ist einfach viel zu langsam, um heutigen Anforderungen zu genügen. Seinerzeit hatte ich den 80C552 eingesetzt, der mit seinen CT0I - CT3I - Eingängen erste Ansätze für flankengetriggerte Interrupts bot, allerdings viel zu lahm war. Nimm mindestens einen AVR (ATmega88, wie in meinem Codeschnipsel) und takte ihn mit 20 MHz. Walter T. schrieb: > Eine Menüsteuerung würde ich nur im Notfall damit machen. Die feine > Einteilung müßte ich für eine sinnvolle Menü-Bedienbarkeit massiv > herunterteilen und die fehlenden Rasten stören da auch Sag das nicht! Mit besagtem C552 und HP-Drehgeber (64 Pos./U, glaube ich) hatte ich ein 'Radio' gemacht. Entscheidend dabei ist, eine Drehdynamik einzubauen und nach kurzer Zeit den internen Hilfszähler auf 0 zu setzen, um damit einen virtuellen Rastpunkt zu schaffen. Oben hatte ich einen Link auf einen Drehgeber mit Schrittmotor, wo dies auch implementiert ist. Vieleicht mal lesen ;-)
m.n. schrieb: > Torsten C. schrieb: >> Oder reagiert der Interrupt immer auf beide Flanken >> und wertet Ihr dann den Pegel in der ISR aus? > So ist es einfacher. Einfacher war nicht die Frage, es geht darum, wie man die Erkennung sicher macht. Also: Tiefpass ist klar, steht hier schon mehrfach, damit der Pegel nicht wechselt, bis die ISR durch ist. Ich frage, denn man könnte die Flanken-ISR-Flags des B-Signals ja auch in der A-Signal ISR auswerten und das B-Signal höherfrequent entprellen, falls das noch sicherer gegen Falsche Zählungen ist. m.n. schrieb: > Sofern man nicht höchste Auflösung braucht Quark. Die gesuchte Auflösung ist von Rastpunkt zu Rastpunkt und bezieht sich auf das rechte Diagramm in 'screenshot25.png'^^. Also nur eine ISR für Signal A. OK.
:
Bearbeitet durch User
Torsten C. schrieb: > Einfacher war nicht die Frage, es geht darum, wie man die Erkennung > sicher macht. Also: Tiefpass ist klar, steht hier schon mehrfach, > damit der Pegel nicht wechselt, bis die ISR durch ist. Hast Du mein Beispiel nicht gesehen oder nicht verstanden? Der Zustand wird einmalig zu Beginn der ISR gelesen und kann sich dann ruhig wieder ändern. Du kannst natürlich auch beliebig die Flankenerkennung umschalten und damit jede Menge zusätzlich Interrupts erzeugen, wenn das für Irgendetwas gut sein sollte. Torsten C. schrieb: > Ich frage, denn man könnte die Flanken-ISR-Flags des B-Signals ja auch > in der A-Signal ISR auswerten und das B-Signal höherfrequent entprellen, > falls das noch sicherer gegen Falsche Zählungen ist. Wozu, um es unnötig kompliziert zu machen? Torsten C. schrieb: > Quark. Zwitscher liefert die bessere Perspektive.
Reiner W. schrieb: > Naja, sicher ne gute Programmierübung. (siehe Bild) Das sieht kräftig nach Übersprechen aus. Die Störungen treten gehäuft auf, wenn der andere Kanal schaltet.
Mike schrieb: > Das sieht kräftig nach Übersprechen aus. Die Störungen treten gehäuft > auf, wenn der andere Kanal schaltet. Das ist halt die Realität. Mit Polling hat man dabei keinerlei Probleme und braucht keine Zusatzhardware.
Angehängte Dateien:
-
Drehgeber_2.png
78 KB
Mike schrieb: > Das sieht kräftig nach Übersprechen aus. Die Störungen treten gehäuft > auf, wenn der andere Kanal schaltet. Die Bilder sind im Rahmen einer größeren Arbeit über die Ankopplung von Drehgebern an PSoC 4 in Hard- und Software entstanden. Das Bild zeigt den interessanten Bereich. Dabei wurde nicht untersucht, welchen Einfluss der Messaubau, Übersprechen oder der verwendete Oszi (Digilent Elektronik Explorer) hatten. Gemessen wurde direkt an den Encoderausgängen bei direkter hochohmiger Belastung durch die Porteingänge. Die PSoC Chips liefern ja interne Quadraturdecoder mit, mit denen sich die Encoder absolut sauber lesen lassen, auch wenn sie wie im Bild prellen (oder aus anderen Gründen Störimpulse aufweisen). Da die Hardwareressourcen der PSoC4 Chips aber recht begrenzt sind, habe ich noch eine reine Softwarelösung nach Peters Vorschlag getestet, die ja mit einem Minimum an Software auskommt. Praktisch konnte ich keinen Qualitätsunterschied feststellen (wohlgemerkt im Anwendungsfall eines Drehgebers zur manuellen Eingabe) Ich habe Alps EC11 und die Pollin-Panasonic Teile verwendet. Vorteil der Softwarelösung ist zudem die Tatsache, dass damit ohne viel Aufwand eine Multiplexbetrieb mehrere Drehgeber realisiert werden konnte. Auch wenn ich in Software nur die Lösung nach PD getestet habe (Timer IR), will ich damit ausdrücklich nicht behaupten oder suggerieren, dass eine Flanken-IR Lösung schlechter wäre, da ich das nicht getestet habe (was sicher nicht uninteressant wäre). Michael B. schrieb: > Mit Polling hat man dabei keinerlei Probleme und braucht keine > Zusatzhardware. Ja, das haben meine eigenen Untersuchungen gezeigt. Aber auch das sagt natürlich nicht, dass das mit Flanken-IR nicht gegangen wäre ;-)
Walter T. schrieb: > vloki schrieb: >> Also dann zum Drehgeber immer gleich eine Bohrfräsmaschine mitliefern, >> damit der Benutzer auch "richtig" drehen kann oder was ? > > Dich interessiert also nicht, welcher Effekt durch den Drehgeber und > welcher durch den Nutzer kommt? Man muss da immer das Gesamtsystem sehen. Wenn kein Nutzer mitspielt, dann brauche ich auch keinen Drehgeber. Aber natürlich, wenn man das Gesamtsystem verbessern wollte, dann muss man natürlich wissen, wer für welchen Effekt verantwortlich ist. Anscheinend funktioniert es so wie es ist ausreichend gut.
Volker S. schrieb: > Anscheinend funktioniert es so wie es ist ausreichend gut. Wie meinst Du das? a) Mit fehlerhaften Zählungen (dann muss ich User halt einen Raster weiter drehen) ausreichend gut? b) Mit Timer- oder Flanken-Interrupt oft genug exakt?
Torsten C. schrieb: > Mal zwei Fragen an die Flankeninterrupt-Fraktion: > > 1) Schaltet Ihr die Flanken-Interrups in der ISR immer zwischen steigend > und fallend um? Oder reagiert der Interrupt immer auf beide Flanken > und wertet Ihr dann den Pegel in der ISR aus? > > Volker S. schrieb im > Beitrag "Re: Drehimpulsgeber" >> Es gibt mindestens zwei unterschiedliche Konzepte. > > Bezogen auf das rechte Diagramm in 'screenshot25.png', wo das Signal B > im Rastpunkt unbestimmt ist: > > 2) Macht Ihr den Flankeninterrupt nur bei Signal A > oder auch bei Signal B? 1. kommt drauf an, ob es ein Drehgeber mit gleich vielen Rastpunkten wie Pulsen ist. Wenn es zu jedem Rastpunkt einen Puls gibt, dann machtdas Umschalten keinen Sinn. Wenn das Signal wechselt, dann wechselt auch die aktive Flanke. In beiden Fällen ist immer nur eine Flanke aktiv. 2. Signal A ist anscheinend immer das halbwegs definierte und wird für den IR genommen, der dann Signal B checkt. (Dass die Flanke von Signal B direkt auf dem Rastpunkt liegt könnte man aus vielen Datenblättern deuten, wenn man den lustigen Satz ignoiert, der meist dabei steht)
:
Bearbeitet durch User
Torsten C. schrieb: > Volker S. schrieb: >> Anscheinend funktioniert es so wie es ist ausreichend gut. > > Wie meinst Du das? > > a) Mit fehlerhaften Zählungen (dann muss ich User halt einen Raster > weiter drehen) ausreichend gut? > > b) Mit Timer- oder Flanken-Interrupt oft genug exakt? c;-)
Volker S. schrieb: > 1. kommt drauf an, ob es ein Drehgeber mit gleich vielen Rastpunkten wie > Pulsen ist. Wenn es zu jedem Rastpunkt einen Puls gibt, dann machtdas > Umschalten keinen Sinn. *Wenn das Signal wechselt,* also bei den Typen mit doppelt so vielen Rastpunkten wie Pulsen ...
Volker S. schrieb: > 1. kommt drauf an, ob es ein Drehgeber mit gleich vielen Rastpunkten wie > Pulsen ist. Es ist ein Drehgeber, wie im rechten Diagramm in 'screenshot25.png', so wie Du es zitiert hast: Signal A ist deterministisch und wechselt zwischen den Rastpunkten, an Signal B kann man die Richtung erkennen und es ist im Rastpunkt nicht definiert. Man darf Signal B nur nicht abfragen, wenn es noch prellt und gerade 'falsch' ist. Ich frage euch nur, ob man vom B-Signal besser die Flanken-Flags oder den Polling-Zustand in der Signal-A-ISR abfragt. @Timer-Fraktion: Nicht meckern! Ich versuche zu verstehen, wie die Flanken-Fraktion denkt. Vielleicht ist ja was dran. Die meisten MCUs haben Schmitt-Trigger-GPIOs und ein Kondensator kommt ja schon durch die Leiterbahnen zustande.
:
Bearbeitet durch User
Torsten C. schrieb: > Es ist ein Drehgeber, wie im rechten Diagramm in 'screenshot25.png', so > wie Du es zitiert hast: Signal A ist deterministisch und wechselt > zwischen den Rastpunkten, an B kann man die Richtung erkennen und es ist > im Rastpunkt nicht definiert. Es ist erstens völlig egal, ob Signal B im Rastpunkt definiert ist, weil es nur bei der Flanke von A definiert sein muss und zweitens glaube ich dass die Position des Rastpunktes in Bezug auf Signal B nicht definiert ist und nicht das Signal B im Rastpunkt. (Die Diagramme oder ich sind einfach blöd) <edit>Ich sehe gerade du hast noch was dazu geschrieben. Ja, der Zustand von B beim FLankeninterrupt von A Nochmal ja, IR Pins haben meist Schmitt Trigger Charakteristik
:
Bearbeitet durch User
Volker S. schrieb: > Es ist erstens völlig egal … und zweitens glaube ich … Sag ich ja, aber aus der Flankenwechsel-Interrupt-Fraktion kommen trotzdem keine Antworten. Und glauben tun wir in der Kirche, der Unterschied läuft auf das selbe hinaus, daher egal.
Torsten C. schrieb: > Sag ich ja, aber aus der Flankenwechsel-Interrupt-Fraktion kommen > trotzdem keine Antworten. Kannst du die Frage nochmal stellen ? Die Typen, die für jeden Rastpunkt einen Puls liefern mag ich sowieso lieber. Die sind im Ruhezustand immer aus und "verschwenden" keinen Strom. Flanken muss man auch nicht wechseln. Fallende Flanke A reicht völlig aus. <edit>btw: weil es mich auch interessiert hat und mein Englisch nicht so gut ist um den Hinweis im Datenblatt zweifelsfrei zu überstetzen, habe ich schon mal versucht zu analysieren wie das mit dem Rastpunkt und dem Zustand von Signal B bei so einem ominösen Teil ist. Da wackelte nichts. Vieleicht kann Walter T. ja noch mal ...
:
Bearbeitet durch User
Volker S. schrieb: > Kannst du die Frage nochmal stellen ? Rechtes Diagramm (EC11E/G/J) in https://www.mikrocontroller.net/attachment/262329/screenshot25.png oder https://www.mikrocontroller.net/attachment/262319/Durchklingeln2.png Signal A ist im Rastpunkt eindeutig, Signal B nicht. Ich hatte zwei Fragen an die Flankeninterrupt-Fraktion, zum besseren Verständnis: 1) Schaltet Ihr die Flanken-Interrups in der ISR immer zwischen steigend und fallend um? Oder reagiert der Interrupt immer auf beide Flanken und wertet Ihr dann den Pegel in der ISR aus? Hintergrund: Falls man den Pegel in der ISR auswertet, könnte er wegen des Prellens ja gerade zufällig 'falsch' sein, und die Pegel-Abfrage dauert zusätzlich Zeit. 2) Macht Ihr den Flankeninterrupt nur bei Signal A oder auch bei Signal B? Inzwischen klar: Nur bei Signal A. Frage: 2a) Wertet Ihr in der Signal-A-Flanken-Interrupt-Routine das Flankenwechsel-Flag von Signal B aus (wenn ja welches: Eins oder beide?), oder nur den Polling-Status? m.n. schrieb: > Hast Du mein Beispiel nicht gesehen …? 100e von Interpretationsmöglichkeiten. Dein Beispiel ist eher was für ein Telefonat als für ein Forum. "ja" oder "nein" wäre als Antwort einfacher, als …
:
Bearbeitet durch User
Torsten C. schrieb: > Dein Beispiel ist eher was für ein Telefonat als für ein Forum. > "ja" oder "nein" wäre als Antwort einfacher, als … Jetzt wird hier seit Tagen darüber diskutiert, wobei sich jeder einfach einmal ein kurzes Programm schreiben könnte, um selber seine Erfahrungen zu machen. Das ist doch Alles supersimpel! Aber nein, es ist ja viel einfacher seine Vorurteile zu pflegen - tagelang und immer wieder, wie bei Fußballvereinen und Fremdenfeindlichkeit. Torsten C. schrieb: > Flankenwechsel-Interrupt-Fraktion Geh mal davon aus, daß diese Fraktion beide Verfahren kennt und beherrscht und in der Lage ist, für den jeweiligen Anwendungsfall das Passende auszusuchen.
Torsten C. schrieb: > Die meisten MCUs haben Schmitt-Trigger-GPIOs > und ein Kondensator kommt ja schon durch die Leiterbahnen zustande. Das nützt nicht viel. Wenn du dir die Oszillogramme von oben nochmal anschaust, siehst du ja, was der Schmitt-Trigger dann sauber in high und low umwandelt, das ist bei einem prellenden Drehgeber immer noch nicht eindeutig. Du musst also auf Plausibilität prüfen. Ich habe das damals so gemacht, das ich etwa 30-mal hintereinander auf gleiche Polarität prüfte - wenn bestanden, dann Auswertung, wenn nicht bestanden, raus. Das klappt schon, aber man verschwendet dann doch so viel Zeit im Flankeninterrupt, das die Timer Routine wieder besser abschneidet. Der Kondensator hat bei einigermassen sauberer Leitungsführung ein paar pF bis ein paar dutzend pF, das reicht nicht. Unabhängig von Timer oder Flanke ist es aber eh empfehlenwert, ein wenig ESD Vorkehrung zu treiben, da es sich ja auch um Dreh-Benutzer mit Wollpullover handeln kann. Also wenn möglich, Drehgebergehäuse erden und RC Glieder in die Leitungen. Ich habe auch öfter mal einen Wegwerf-74HC14 in die Leitungen gesetzt, um den MC zu schützen.
Matthias S. schrieb: > Ich habe das damals > so gemacht, das ich etwa 30-mal hintereinander auf gleiche Polarität > prüfte - wenn bestanden, dann Auswertung, wenn nicht bestanden, raus. Wann, mit welchem Prozessor und wie programmiert? Wiederhole das doch noch einmal mit heutigen µCs und mit Deinen heutigen Erfahrungen. Soweit ich mitbekommen habe, setzt Du ja auch AVRs ein, wofür viele Beispiele (auch für Arduino Uno) vorhanden sind: Beitrag "Drehgeber per Interrupt auswerten, AVR" Wie gesagt, es ist supersimpel! Matthias S. schrieb: > Also wenn möglich, Drehgebergehäuse erden und RC Glieder in die > Leitungen. Wenn Du schon RC empfiehlst, mit 10 kOhm und 100 nF bekommst Du die Signaländerungen so langsam, daß man schon fast mit scharfem Hinsehen auswerten kann. RC ist auch immer wieder interessant. Wenn das Jemand für Drehgeber verwendet, wird wild gechimpft, daß das Alles viel zu aufwendig wäre. Falls hier Jemand nach dem Schutz von ADC-Eingängen fragt, wird man von Vorschlägen fast erschlagen, die eine Menge Rs und Cs und auch noch Schutzdioden vorsehen, obwohl Letztere schon im µC vorhanden sind. Immer so, wie es gerade in den Kram paßt.
m.n. schrieb: > Wann, mit welchem Prozessor und wie programmiert? Das fing etwa 1980 mit 6502 an, über Z80 und MCS51. Bei denen natürlich alles in ASM. Bei den ersten beiden war mangels Hardware ein Timer nicht drin, in den letzten MCS51 Projekten dann aber schon. m.n. schrieb: > Wenn das Jemand für Drehgeber > verwendet, wird wild gechimpft, daß das Alles viel zu aufwendig wäre. Nicht für mich. Leitungen, die direkt vom Benutzer in den MC gehen, sind mir suspekt und ich schütze da gerne ein wenig. Sind aber eher 10k und 470pF - 10nF. m.n. schrieb: > Soweit ich mitbekommen habe, setzt Du ja auch AVRs ein, > wofür viele Beispiele (auch für Arduino Uno) vorhanden sind: > Beitrag "Drehgeber per Interrupt auswerten, AVR" > Wie gesagt, es ist supersimpel! Mittlerweile ist da auch viel STM32 bei. Aber supersimpel finde ich mittlerweile die Timernummer. Wie ich oben schon schrieb, packe ich mittlerweile Buttons und Drehgeber in die gleiche Routine und frühstücke damit das ganze Benutzergedöns in einer Routine ab, die auch noch eine immer vorhersehbare Laufzeit hat.
:
Bearbeitet durch User
Matthias S. schrieb: > Das fing etwa 1980 mit 6502 an, KIM, AIM, ACORN? Oder gar PET oder Apple? Irgendwann gab es ja den 6532 mit RAM und Timer ;-) Matthias S. schrieb: > Leitungen, die direkt vom Benutzer in den MC gehen, sind > mir suspekt und ich schütze da gerne ein wenig. Sind aber eher 10k und > 470pF - 10nF. Full Ack, und sofern schnellere Signale im Spiel sind kommen MC1489 o.ä. dazwischen: Überspannungsschutz, Signalformer und bei Bedarf auch noch mit ESD-Schutz.
Volker S. schrieb: > <edit>btw: weil es mich auch interessiert hat und mein Englisch nicht so > gut ist um den Hinweis im Datenblatt zweifelsfrei zu überstetzen, habe > ich schon mal versucht zu analysieren wie das mit dem Rastpunkt und dem > Zustand von Signal B bei so einem ominösen Teil ist. Da wackelte nichts. > Vieleicht kann Walter T. ja noch mal ... Was ist die Frage? Welcher "Hinweis" im Datenblatt? Beim Panasonic-Encoder ist der Flankenwechsel von B im Verhältnis zu Rastpunkt nicht genau definiert. Was auch irgendwie sinnvoll ist: Wenn man bedenkt, daß das Teil für Automobil-Anwendungen gedacht ist und bei der üblichen Vibration im Fahrzeug auch mal gern um den Rastpunkt schwingen kann, wäre es fatal, wenn sich der Softwareentwickler auf ein irgendwie definiertes Verhalten von B im Rastpunkt verlassen würde.
:
Bearbeitet durch User
m.n. schrieb: > Oder gar PET oder Apple? Bei mir Apple ][. Ich hatte damals ein Projekt, um einen Videoschnittplatz mit der Kiste zu steuern, die aus mehreren Philips Zuspielern mit I²C und einem U-Matic Monster mit Parallelschnittstelle bestand. Der Apple wurde mit der Apple Maus und einem selbstgebauten Pult mit Drehgebern und Digitastern gesteuert. In zwei Slots steckten Karten mit 6522, die eine musste dutzende von Leitungen des U-Matic steuern und die andere machte I²C per Bitbanging. m.n. schrieb: > kommen MC1489 o.ä. > dazwischen Ich nehme die 74HC14, weil ich die säckeweise habe, aber es geht ja so gut wie alles, was einen Eingang und einen Ausgang hat.
Matthias S. schrieb: > Mittlerweile ist da auch viel STM32 bei. Na gut, aber im Grunde mußt Du ja nur die Hardware Deines 3-Phasen Frequenzumrichters nehmen: ein Display ist vorhanden und an INT0 ist ja schon C13 mit 2,2 nF vorhanden. Für die andere Drehgeberphase kannst Du einfach PD1 nehmen ;-)
Ach herrje.. ihr diskutiert ja immer noch! Torsten C. schrieb: > Signal A ist im Rastpunkt eindeutig, Signal B nicht. > Ich hatte zwei Fragen an die Flankeninterrupt-Fraktion, zum besseren > Verständnis: zu 1. (welche Flanken) Die allermeisten DG liefern einfach nur zwei um 90° +/-30° versetzte Signale. Eines von denen ändert sich in der Nähe des Rastpunktes. Das ist das Signal, was nur zur Richtungsermittlung in der ISR abgefragt wird. Nennen wir es hier mal "D": Das andere Signal ändert sich so etwa auf halber Strecke zwischen den Rastpunkten. Das ist das Signal, was die Flankeninterrupts auslöst. Und zwar auf beiden Flanken. Nennen wir es hier mal "I". Ich räume ein, daß es bei älteren µC schwierig war, den betreffenden Pin so einzurichten, daß er bei beiden Flankenwechseln einen Interrupt liefert. Vielleicht kommen daher die Bedenkenträger, die lieber pollen wollen. zu 2. (Auswertung) Beim Interrupt auf Flanke ist ja völlig klar, daß es eine Drehbewegung gegeben hat. Da bleibt in der ISR nur übrig, die Richtung festzustellen. Das macht man durch Abfragen des anderen Signals, was sich ja beim Rastpunkt ändert und demzufolge zum Zeitpunkt des Interrupts stabil ist. Dieses Signal ist ja quasi um (etwa) 90° vor- oder nachlaufend, so daß man die Richtung ganz einfach durch ein XOR beider Signale erhält. Also Richtung = I xor D; Das war's schon. Wie man sieht, braucht die Flankenmethode keinerlei gespeicherte Informationen über einen vorherigen Zustand. Die Pollingmethode hingegen benötigt diese Informationen, da sie ja sonst die Änderung des Zustandes nicht erkennen kann. W.S.
Günter Lenz schrieb: > Wenn ein Drehgeber das macht, was Volker SchK > in screenshot27.png zeigt, ist das meiner Meinung > nach Herstellerpfusch. Der Hersteller sollte schon > 90 grad Versatz anstreben, zu mindest 45 grad. > Rastpunkt auf einer Flanke ist nach meiner Meinung > auch Herstellerpfusch. Am besten man nimmt Drehgeber > die Optisch abgetastet werden, die haben keinen Verschleiß > und prellen nicht. Du vergißt die Handhabung des Ganzen. Also ich erkläre es dir mal im Detail: Einen DG mit Rastung drehen zu wollen bedeutet, daß man zunächst etwas Kraft aufwenden muß, um ihn aus seiner Rastung herauszubekommen. Nun ist der Mensch mit seinen Knochen aber keine Werkzeugmaschine, die man um einen gewünschten Winkel verstellt, sondern der menschliche Bewegungsapparat ist was eher elastisches. Deshalb ändert sich der Winkel des DG zunächst garnicht, bis deine Finger soviel Drehmoment aufgebaut haben, daß dies das Rastmoment übersteigt. Dann entspannt sich das Ganze aber mit nem Ruck, bis man in der nächsten Rastung landet. Deshalb ist die Drehgeschwindigkeit beim händischen Drehen zeitlich höchst unterschiedlich (eben ruckhaft) - was man mit einem Oszi, der mit konstanter Geschwindigkeit aufzeichnet, SO nicht wirklich sehen kann. Das Ganze ist deshalb eben kein Herstellerpfusch. Dieses Bild ist übrigens durchaus erhellend, die Pollingmethode betreffend: Es zeigt uns nämlich, daß bei gewöhnlicher händischer Betätigung der DG die meiste Zeit in der Nähe eines seiner Rastpunkte sich befindet und die Annahme, daß man ja bloß mit dem 4fachen der erwartbaren Rastpunktfrequenz zu pollen braucht, eben falsch ist. Stattdessen muß manmindestens mit der doppelten Frequenz pollen, die dem zeitlichen Versatz der im Bild sichtbaren blauen und gelben Kurve entspricht. Und das ist (geschätzt) weniger als 1/25 der Signalperiode. Wenn die Zahl von 34.1ms als Periodenlänge stimmt, dann müßte man mindestens alle 680µs pollen. W.S.
W.S. schrieb: > Deshalb ist die Drehgeschwindigkeit beim händischen Drehen zeitlich > höchst unterschiedlich (eben ruckhaft) - was man mit einem Oszi, der mit > konstanter Geschwindigkeit aufzeichnet, SO nicht wirklich sehen kann. Die eben nicht konstante Drehgeschwindigkeit ist ja auch nicht interessant, sondern nur das was auch der uC sozusagen "sieht" und das ist nun mal das Signal, wie es am Oszi angezeigt wird. (Was dir und mir vermutlich eh klar ist ;-) Wie man das dann auswertet, über Polling oder IR, kann man immer noch in jedem Einzellfall individuell entscheiden ... (Individualismus ist für die Poller anscheinend ein böööööses Wort;-)
:
Bearbeitet durch User
Volker S. schrieb: > Individualismus ist für die Poller anscheinend ein böööööses Wort;-) Poller stehen oft auch nur sinnlos auf Radwegen herum. ;-) mfG Paul
Am einfachsten wäre es, wenn beide Fraktionen sich aus Diskussionen der jeweils anderen Fraktion raushalten. Aber das wäre dann so, wie wenn man C++ Fragen diskutiert und Moby und c-hater halten sich raus. Also unmöglich!
Walter T. schrieb: > Volker S. schrieb: >> <edit>btw: weil es mich auch interessiert hat und mein Englisch nicht so >> gut ist um den Hinweis im Datenblatt zweifelsfrei zu überstetzen, habe >> ich schon mal versucht zu analysieren wie das mit dem Rastpunkt und dem >> Zustand von Signal B bei so einem ominösen Teil ist. Da wackelte nichts. >> Vieleicht kann Walter T. ja noch mal ... > > Was ist die Frage? Welcher "Hinweis" im Datenblatt? > > Beim Panasonic-Encoder ist der Flankenwechsel von B im Verhältnis zu > Rastpunkt nicht genau definiert. Genau das ist die Frage. Was bedeutet der Hinweis im Datenblatt "The stable detent position cannot be identified in phase B" Ich würde es so auslegen wie du. Torsten C. eher anders: Torsten C. schrieb: > Bezogen auf das rechte Diagramm in 'screenshot25.png', wo das Signal B > im Rastpunkt unbestimmt ist: Man könnte jetzt natürlich wieder sagen, dass das beides auf selbe hinaus laufen könnte ;-)
Bastler schrieb: > Am einfachsten wäre es, wenn beide Fraktionen sich aus Diskussionen der > jeweils anderen Fraktion raushalten. Ja das wäre vermutlich das Beste für diejenigen, die hier fragen, weil sie sich erst mal klar werden müssen, was die Drehgeber überhaupt für Signale liefern und dann irgendwann später entscheiden müssen wie diese Signale im Einzelfall am besten ausgewertet werden ... Bastler schrieb: > Aber das wäre dann so, wie wenn man > C++ Fragen diskutiert und Moby und c-hater halten sich raus. Also > unmöglich! Ja ;-) Bestimmt ist mal das eine von Vorteil, mal das andere und oft genug wahrscheinlich scheiß egal.
:
Bearbeitet durch User
m.n. schrieb: > Na gut, aber im Grunde mußt Du ja nur die Hardware Deines 3-Phasen > Frequenzumrichters nehmen: Der FU benutzt allerdings eine völlige andere Eingabe Strategie. Hier wird nur zyklisch (aus der Hauptschleife) die Eingabetastenroutine aufgerufen und Drehgeber gibts hier gar nicht. Interrupts (gar PCINT oder Ext. Int) sind tabu, weil die Erzeugung der Phasen immer oberste Priorität haben muss und die Priorität der ISR im AVR festgelegt ist. Ein Motor darf ja nicht ruckeln, nur weil mal jemand am Rad dreht :-) Übrigens würde auch in diesem Projekt ein gepollter Drehgeber mit abfallen, wenn man es an die zentrale Timerroutine anhängen würde.
Matthias S. schrieb: > Der FU benutzt allerdings eine völlige andere Eingabe Strategie. Die Du hier völlig ignorieren solltest, genauso wie den Motor und alles Andere auch! Ich meinte lediglich, daß Du ohne große Lötarbeit Dein Stück Hardware nehmen könntest, um die generelle Funktion des gezeigten Programmes (Drehgeber per Interrupt auswerten) zu testen und auf dem LCD anzeigen zu lassen. Danach könntest Du in der Lage sein, Deine alten Vorurteile abzulegen. Egal, was Du machst, ein "ja aber" möchte ich dann nicht mehr hören! Bastler schrieb: > Am einfachsten wäre es, wenn beide Fraktionen sich aus Diskussionen der > jeweils anderen Fraktion raushalten. Im Grunde würde es schon reichen, wenn sich dieser armselige Hassprediger fernhalten würde. Dann könnte man viel sachlicher diskutieren.
m.n. schrieb: > Danach könntest Du in der Lage sein, Deine alten Vorurteile > abzulegen. Brauche ich doch gar nicht. Gerade ich gehöre zur Fraktion derer, die das alles schon hinter sich haben und ihre Vorurteile immer wieder hinterfragt haben. Ich bleibe also von nun an beim timergesteuerten Polling.
Matthias S. schrieb: > Ich bleibe also von nun an beim timergesteuerten > Polling. Immer und in jedem Fall ? Du kennst doch bestimmt noch diese Quartett Kartenspiele ? Du weist schon, die man nie als Quartett spielt, sondern immer irgendwelche Werte vergleicht und wer "besser" ist gewinnt den Stich. Ein Flugzeugträger gewinnt da bestimmt immer gegen "Hüpfen" ;-) Aber ist ein Flugzeugträger in der Realität WIRKLICH so gut geeignet einen 50cm breiten Bach zu überqueren ?
Genau! Und deshalb hüpft man über den kleinen Bach oder polkt den Drehgeber zur Menübedienung. Der Flugzeugträger wäre hier der optische Winkelencoder mit 500kHz.
Matthias S. schrieb: > Gerade ich gehöre zur Fraktion derer, die > das alles schon hinter sich haben Und dann schreibst Du: Matthias S. schrieb: > Ich habe das damals > so gemacht, das ich etwa 30-mal hintereinander auf gleiche Polarität was mir eigentlich sagt, daß Du auf diesem Gebiet unerfahren warst und wohl auch geblieben bist. Auch stolpere ich darüber, daß Du Deine Polling-Routinen nicht selber geschrieben hast, sondern dafür eine ext. Quelle brauchtest. Für mich Alles ein Zeichen, daß Du Dich durchaus nicht zurücklehnen solltest und Deine Rentenpunkte zählen kannst!
Warum sollte man auch alles neu erfinden wollen. Mit der Einstellung sollte man Keim Forum besuchen, denn da geht es um Gedanken-AUSTAUSCH und nicht ums Predigen der einen, heiligen Wahrheit. PS.: Ich habe weder mein BS, noch meinen Browser, noch ... selbst geschrieben, noch fühle ich mich schlecht dabei, Dinge zu benutzen, die Andere erfunden haben.
m.n. schrieb: > Auch stolpere ich darüber, daß Du Deine Polling-Routinen nicht selber > geschrieben hast, sondern dafür eine ext. Quelle brauchtest. Ach - ob du es glaubst oder nicht, ich benutze sogar MC und Prozessoren, die ich von Zulieferern beziehe. Ich lese auch Bücher, die ich nicht selber geschrieben habe und spiele eine Gitarre aus den USA. Das ist doch ein albernes Argument, vermutlich, weil dir die brauchbaren gerade ausgegangen sind. Warum soll ich denn das Rad neu erfinden, wenn ich die Routinen gut verstehe und problemlos auf jeder Plattform benutzen kann?
Womöglich hast du auch die ECC83 im deinem Bass-Verstärker nicht selbst mundgeblasen? Unfaßbar ;-))
Hallo, ich bin wieder da;-) Lese mit Interesse Eure diskussion. Ich möchte mal das Subjekt der Diskussion von einer neuen Seite beleuchten. In vielen uC Anwendungen braucht man zur zeitlichen Ablaufsteuerung des eigentlichen Anwendungsprogramm sowieso oft eine Timer ISR im ms Bereich. Da feststeht, dass Polling durchaus für mechanische DG gut genug funktioniert, macht es also nicht viel aus wenn man die DG Abfrage mit in die schon vorhandene ISR mitintegriert. Die armseligen paar CPU Zyklen dazu macht der uC doch lässig mit und ist bei den vielen MIPS der neuzeitlichen uC doch meist vernachlässigbar. Wenn im Programm allerdings keine langsame Ablaufsteuerung vorhanden ist dann hätte das besprochene DG Interrupt Verfahren durchaus Vorteile, solange durch entsprechende Beschaltung oder algorithmischen Kunstwerk sichergestellt wird dass Kontaktprellungen sich nicht mehr negativ auswirken können. ESD Vorkehrungen und Schutz/Filtern der (ISR) uC Eingänge sind selbstverständlich Stand der Technik im professionellen Bereich und brauchen auch hier auch gar nicht mehr erwähnt zu werden. Wenn man sich gut mit der Materie auskennt kommt man auch auf beiden Wegen zum Ziel. Mfg, Gerhard
m.n. schrieb: > Jetzt wird hier seit Tagen darüber diskutiert, wobei sich jeder einfach > einmal ein kurzes Programm schreiben könnte, um selber seine Erfahrungen > zu machen. Das ist doch Alles supersimpel! Welche Erfahrung soll er machen ? Daß es mit Polling immer geht, wenn man ausreichend schnell abtastet, und mit Flankeninterrupt nur manchmal, so dass es für zuverlässigen Betrieb notwendig wird externe Zusatzhardware zu ergänzen. Blöde Erfahrung, dann doch lieber gleich die richtige Methode nehmen statt ewig an falschem herumzudoktorn wie du.
Nur daß es eben 2 Ziele gibt und zu jedem gibt es einen besten Weg. Nur wenn man die "2" nicht verstanden hat, muß man über den Weg diskutieren.
Bastler schrieb: > Womöglich hast du auch die ECC83 im deinem Bass-Verstärker nicht selbst > mundgeblasen? Unfaßbar ;-)) [OT]Ich habe sie sogar mittlerweile rausgeschmissen und durch einen selektierten FET mit Spannungsfolger ersetzt. Selektiert habe ich aber selber, nur der FET ist von Toshiba :-) [/OT]
[ot] welcher genau? Und wie erträgst du das Wegeschrei der kalten Elektronen?[/ot]
Hab ich das Ironie-Icon vergessen? ;-)) Das war eine Anspielung darauf, daß Matthias früher Verfechter heißer Elektronen in leeren Glaskörpern war. Ich hab schon vor 33 Jahren erlebt, wie die Kinnlade eines Vollröhrenbesitzers runterklappt, wenn er gut gemachtes Silizium hört. Gut es lag auch an meiner Gitarre. War viel billiger als seine, aber hatte Humbucker ohne Deckel. Bis ich allerdings verstanden hatte, warum das so klang, sind noch etliche Jahre vergangen.
Bastler schrieb: > Hab ich das Ironie-Icon vergessen? ;-)) Ich fand das mit den Elektronen nur so komisch von Dir und das kam mir dann in den Sinn. Ich habe das schon so verstanden wie Du gemeint hattest. Also nichts für ungut. mfg, Gerhard P.S. [ot]?
:
Bearbeitet durch User
Bastler schrieb: > Warum sollte man auch alles neu erfinden wollen. Muß man nicht, aber der Bedarf an guten Entprellroutinen bestand schon deutlich früher bevor es dieses Forum gab. Und die Chance, daß Herwig Feichtinger etwas Passendes in der MC schrieb, waren auch nicht so groß ;-) Folglich war man seinerzeit auf eigene Routinen angewiesen, wenn man sich heute als alter Hase sehen möchte.
Gerhard O. schrieb: > Die armseligen paar CPU > Zyklen dazu macht der uC doch lässig mit und ist bei den vielen MIPS der > neuzeitlichen uC doch meist vernachlässigbar. Du setzt stillschweigend ein paar Randbedingungen voraus, die praktisch nicht gegeben sind. Die erste ist, daß der angedachte µC so reichlich Zeit und so wenig zu tun hat, daß man seine Rechenzeit verschwenden kann. Gilt nicht wirklich immer. Die zweite ist, daß ein Uhr-Interrupt eine höhere Priorität haben müßte als andere Interrupts, was regelmäßig NICHT der Fall ist bei allen µC, die als Device am USB hängen oder die irgendwelche I2S-Daten streamen und auch noch verarbeiten müssen (Filtern etc, eben alles was man mit simpler DMA nicht machen kann) Die dritte ist, daß es häufig genug Fälle gibt, wo man Strom sparen will/muß und deshalb im Idle-Fall den Takt herunter dreht oder gar den µC schlafen legt. Dort im 700µs - Takt zu pollen, bloß weil man zu dämlich ist, den einen Schleifkontakt per RC zu entprellen, ist albern und nicht zielführend. W.S.
W.S. schrieb: > Du setzt stillschweigend ein paar Randbedingungen voraus, die praktisch > nicht gegeben sind. Deine Argumente sind 100% stichhaltig und unterstreichen dass jedes Design zugeschnittene Lösungen verlangt. Man darf also nicht alles sozusagen über einen Kamm scheren wie es hier so oft geschieht. Das ist schon klar. Gruss, Gerhard
W.S. schrieb: > Die zweite ist, daß ein Uhr-Interrupt eine höhere Priorität haben müßte > als andere Interrupts, was regelmäßig NICHT der Fall ist bei allen µC Aber ein Pinchange Interrupt hat regelmäßig immer höhere Priorität? Das ist gut, denn dann klappt auch das Abfragen des Pegels problemlos. > Die erste ist, daß der angedachte µC so reichlich Zeit und so wenig zu > tun hat, daß man seine Rechenzeit verschwenden kann. Wenn der uC so knapp auf Kante genäht ist, dass er diese "Reserve" nicht hat, passt (eigentlich) auch kein Interrupt mehr "dazwischen". Nur merkt man das nicht sofort, sondern nur ab&zu bei seltsamem Verhalten.
Die bekannten (AVR) Heizkörperthermostate lösen das Tasten-Problem so: Tief schlafen, erster Tasten-Druck weckt per PinChange, dann Pollen aktivieren (und PinChange aus), wenn lange genug nichts passiert ist, Pollen aus (PinChange wieder ein) und Tiefschlaf. Nur alle Sekunde per async-Timer2 aufwachen um Uhr nachzustellen, jede Minute messen und regeln. Bei Bedarf Ventil bewegen. Manchmal gibt es also nicht nur eine an die Anwendung angepaßte Lösung, sondern zeitabhängig gleich 2. Wenn nur PinChange das beste wäre, dann hätte man die Dinger sicher genau so gebaut.
W.S. schrieb: > Die erste ist, daß der angedachte µC so reichlich Zeit und so wenig zu > tun hat, daß man seine Rechenzeit verschwenden kann. Gilt nicht wirklich > immer. Es kommt letzten Endes wirklich auf die Anwendung an. Wenn man nicht gerade sehr CPU-Zyklen intensive Programme bauen muß (z.B. Soft MP3, Video, WS2811 LED Treiber u.ae.), laufen doch mehr uC Programme wie man denkt praktisch doch eigentlich fast im Leerlauf und warten auf irgendwelche Stimuli von der Hardware oder dem User, externe Kommunikation, usw. und verbrennen CPU Zyklen. Zumindest ist das bei den meisten Projekten von mir bis auf ein paar seltene Ausnahmen der Fall. Da hat man dann schon einen gewissen Spielraum um den "bequemen" Weg zu gehen. Jede Anwendung hat individuelle Gesichtspunkte und man findet ja schnell genug heraus inwieweit man die Möglichkeiten ausschöpfen muß. uC Programme verhalten sich oft wie im wirklichen Leben ähnlich wie gewisse Autofahrer die mit großer Geschwindigkeit bei einer roten Ampel bremsen müssen um dann wenn es wieder grün wird, wie verrückt aufs Gas zu steigen um das Spiel dann bei der nächsten Kreuzung zu wiederholen. Das bringt nicht viel. Viele Programme scheinen artverwandt strukturiert zu sein. Da hat man einen CPU mit vielen MIPS und man steigt regelmäßig auf die Bremse um auf irgend etwas Wichtiges zu warten. mfg, Gerhard
:
Bearbeitet durch User
Bastler schrieb: > Manchmal gibt es also nicht nur eine an die Anwendung angepaßte Lösung, > sondern zeitabhängig gleich 2. Wenn man das so bei einem Drehgeber macht, würde ich nicht zustimmen. Das ist für mich wie ein Auto mit zwei Schlüsseln: einer zum Türöffnen und einer zum Starten. Mein Auto braucht nur einen Schlüssel :-) > Wenn nur PinChange das beste wäre, dann > hätte man die Dinger sicher genau so gebaut. Nur, weil jemand das kommerziell so ausführt, muß es noch lange nicht das gelbe vom Ei sein. Dabei denke ich an den Timer meines Küchenherdes (Bosch); da hat man ja nicht einmal das Pollen auf die Reihe bekommen. Bei wenigen Tasten (4-5), die zudem nicht auf der Platine direkt sitzen, würde ich beim Interrupt bleiben, wobei der µC den Kondensator am Eingang aktiv läd bzw. entläd, um die max. RC-Verzögerungszeit unter allen Umständen sicherzustellen. Ein Beispiel wäre ein "Fahrrad-Computer" mit zwei Tasten und einem Impulsgeber. Gerhard O. schrieb: > Es kommt letzten Endes wirklich auf die Anwendung an. Volle Zustimmung!
Walter T. schrieb: > Dr. Walter Tarpan > Lehrstuhl für Bedienelementesinologie > TU Osnabrück hier der fehlende Bezug ....
Walter T. schrieb: > Ein Witz wird nicht dadurch besser, daß man ihn erklärt. Du könntest aber erklären WO der Witz vorkam. Manch Einer fand ihn auch nach intensiver Suche nicht.
Naja, wer einen Witz nicht wahrnimmt, hat auch nicht das Gefühl, etwas verpaßt zu haben. vloki schrieb: > [...] Ihr seid mir schon'n paar feine Theoretiker. Bestimmt von der Uni ;-) Walter T. schrieb: > [...] Aber vielleicht liegt es > daran, daß ich tatsächlich von der Uni bin. > > Viele Grüße > W.T. > > -- > > Dr. Walter Tarpan > Lehrstuhl für Bedienelementesinologie > TU Osnabrück
Walter T. schrieb: > Naja, wer einen Witz nicht wahrnimmt, hat auch nicht das Gefühl, etwas > verpaßt zu haben. Jetzt habe ich es gefunden: Du bist gar nicht im Personenverzeichnis der Uni Osnabrück enthalten: http://www.uni-osnabrueck.de/universitaet/personensuche.html?id=&command=starting_with&search_key=T Das ist natürlich so wahnsinnig lustig, da werden meine Enkel noch drüber lachen müssen... :-(((
Kai M. schrieb: > Du bist gar nicht im Personenverzeichnis der > Uni Osnabrück enthalten: Das ist ja auch das Personalverzeichnis der Uni Osnabrück, nicht der TU. Kai M. schrieb: > Das ist natürlich so wahnsinnig lustig, da werden meine Enkel noch > drüber lachen müssen... Nicht jeder muß über einen unschuldigen Scherz lachen- aber breittreten ist schröcklich. Vielleicht sollte man den Teil ab hier: Beitrag "Re: Drehimpulsgeber" inklisive dieses Beitrags einfach wieder löschen - er trägt nichts zum Thema Drehgeber bei.
:
Bearbeitet durch User
Walter T. schrieb: > Vielleicht sollte man den Teil ab hier: > > Beitrag "Re: Drehimpulsgeber" > > einfach wieder löschen - er trägt nichts zum Thema Drehgeber bei. Vollkommen einverstanden.
m.n. schrieb: > Wenn man das so bei einem Drehgeber macht, würde ich nicht zustimmen. > Das ist für mich wie ein Auto mit zwei Schlüsseln: einer zum Türöffnen > und einer zum Starten. Mein Auto braucht nur einen Schlüssel :-) Wenn ich ein Wohnmobil hätte, fände ich's schon praktisch, wenn ich meine Kinder den Schlüssel geben könnte um was rauszuholen, ohne Angst haben zu müssen, das sie damit lostuckern. Nur so als Beispiel :)
Lothar M. schrieb: > W.S. schrieb: >> Die zweite ist, daß ein Uhr-Interrupt eine höhere Priorität haben müßte >> als andere Interrupts, was regelmäßig NICHT der Fall ist bei allen µC > Aber ein Pinchange Interrupt hat regelmäßig immer höhere Priorität? Das > ist gut, denn dann klappt auch das Abfragen des Pegels problemlos. Wo lebst du? OK, wir können hier weiter über Drehknopf-Chinakunde schwafeln - was vielleicht vergnüglicher ist, als sich mit uneinsichtigen Pollern abzugeben - aber es lesen eventuell auch unerfahrene Neulinge mit, die hier keinen solchen Mumpitz lesen sollten. In den hier üblichen Szenen ist es so, daß man die Prioritäten so vergibt, daß das System insgesamt richtig läuft. Und da ist der Systemtick so ziemlich das Letzte, was es so an Interrupts gibt. Ein Pinchange-Interrupt hat also nur dann nen Vorrang über den Systemtick, wenn man ihn dafür einrichtet - und jetzt kommt es darauf an, wie unterbrechungsempfindlich andere Interrupts sind. Er kann der Pinchange also durchaus die höchste Priorität (mal abgesehen von NMI, Faults etc.) haben - wenn er nur saukurz ist. Der entscheidende Punkt ist, daß der Pinchange-Interrupt per Hardware genau zum richtigen Zeitpunkt kommt, also das vor- oder nacheilende Richtungssignal noch stabil ist. Du hast es ja weiter oben gelesen, daß genau dieses in der Nähe des Rastpunktes umschaltet und damit aufgrund der ruckartigen Bewegung die meiste Zeit tatsächlich instabil ist. W.S.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.