Hallo,
Um einen Wechsel an einem Pin zu erfassen, kann man ja zu einem einen
Pin Change Interrupt ausführen, oder diesen Pin immer pollen und sehen,
wann sich der Zustand geändert hat.
Letzteres hat den Vorteil, dass das Prellen abgefangen werden kann. Ist
aber auch etwas langsamer.
Wann fragt ihr wie einen pin ab?
Z.b. wenn ein Taster drann geschlossen ist?
Wenn ihr den pin immer pollt und den Zustand abfragt, macht ihr das in
einem Timer-interrupt oder normal in der while-schleife? (wodurch das
erfassen noch später kommen kann)
Gibt es noch weitere sachen, wovon ihr es abhängig macht, wie ihr einen
pin abfragt?
Hans schrieb:> Wann fragt ihr wie einen pin ab?
Wenn er ein elektronisches, also prellfreies Signal ist: Per Pin Change
Interrupt.
> Z.b. wenn ein Taster drann geschlossen ist?
Da Taster prellen: Immer per pollen, man will niemals die gesamte
Rechenzeit des uC auf Beantwortung von Horden von Interrupts draufgehen
lassen.
Hans schrieb:> macht ihr das in> einem Timer-interrupt oder normal in der while-schleife?
Kommt drauf an. Oftmals ist exaktes Timing egal, dann kommt es in die
main-loop.
Man sollte eine Einstufung der Prioritäten vornehmen...
Je höher die Priorität eines Zustandswechsels am Pin für die
Gesamtfunktion ist, umso mehr muß man ihm diese auch einräumen, z.B.
durch einen Interrupt...
Bei niedriger Priorität ist es Wurscht, ob der Pin in der Mainschleife
je nach Auslastung mal früher oder später gepollt wird...
Ist es ein mechnischer Taster, kommt noch das Entprellen dazu... ein
Timerintervall mit der geeigneten Abtastrate ist ein adäquater Weg
dahin, da die Mainschleife i.d.R. viel zu kurze Intervalle besitzt. Zeit
verplempern durch Warteschleifen ist machbar, bei wenig beschäftigter
CPU und wenn das Programm später nicht mehr erweitert werden soll...
aber man sollte sich die Timerlösung (evtl. mit dem passend getimeten
Watchdog-Int)angwöhnen.
Elektronische generierte Signale frage ich idR in ner ISR ab, mechnisch
generierte Signale (wie z.B. nen Taster) frag ich via Pollen/Timer ab
sofern er nicht prellfrei ist (also eine Hardware-Entprellung oder
ähnliches hat).
Hans schrieb:> Um einen Wechsel an einem Pin zu erfassen, kann man ja zu einem einen> Pin Change Interrupt ausführen, oder diesen Pin immer pollen und sehen,> wann sich der Zustand geändert hat.> Wann fragt ihr wie einen pin ab?> Z.b. wenn ein Taster drann geschlossen ist?
Kommt drauf an. Auch bei einem prellenden Taster kann ein Pin-Change
Interrupt sinnvoll sein. Z.B. um den µC aus dem Tiefschlaf zu wecken.
> Wenn ihr den pin immer pollt und den Zustand abfragt, macht ihr das in> einem Timer-interrupt oder normal in der while-schleife? (wodurch das> erfassen noch später kommen kann)
Pollen zur Entprellung macht man immer unter Verwendung eines Timers.
Da der µC nicht wissen kann, wann der Anwender einen Taster drücken
wird, muß er den Taster ja ohnehin ständig im Auge behalten. Ein
Timer-Interrupt im Hintergrund bietet sich daher an.
Die Alternative wäre, den µC ständig in einer Dauerschleife nur die
Tasten abfragen zu lassen. Wann soll er denn dann noch etwas sinnvolles
tun? So geht das wirklich nur für simpelste Anwendungen.
Axel S. schrieb:> Pollen zur Entprellung macht man immer unter Verwendung eines Timers.
Nur nicht in Dipl.Arbeiten, Lehrbüchern etc. Der Leser ist ja dumm, man
will Ihn ja keinesfalls überfordern. Papier spart's auch noch....
Axel S. schrieb:> Kommt drauf an. Auch bei einem prellenden Taster kann ein Pin-Change> Interrupt sinnvoll sein. Z.B. um den µC aus dem Tiefschlaf zu wecken.
Aber dann eben nur zum Aufwecken. Wenn er läuft, pollt man den Pin.
Hans schrieb:> Wann fragt ihr wie einen pin ab?> Z.b. wenn ein Taster drann geschlossen ist?
Warum stellst du so eine eingeengte Anfrage?
Gibt es etwa nur eine einzige Taste?
Und prellt diese?
Nein, allgemein ist das ja so, daß man nicht nur eine einzige Taste am
Controller dran hat, sondern mehrere - und nichtprellende Tasten gab's
mal, waren aber wegen der dort verbauten Elektronik teuer.
Deswegen sollte man sich eine Systemuhr in der Firmware gönnen, die
einen sinnvollen, niedrig priorisierten Timer-Interrupt erzeugt (zumeist
reicht es aus, alle 10 ms einen davon zu haben). Und eben in dieser ISR
werden dann alle Tasten bzw. die gesamte Tastaturmatrix abgefragt und
ggf. entsprechende Tasten-Ereignise generiert.
Eine Ausnahme gibt es, nämlich Drehgeber. Die haben bei schnellem Drehen
eine für 10 ms Timertick zu hohe Datenrate und das zweite Signal des
Drehgebers (Richtung) muß zeitnah zum ersten Signal erfaßt werden.
Deshalb ist bei Drehgebern eine Hardware-Entprellung und
Interruptbetrieb sinnvoll. Natürlich kann man auch pollen, aber das
muß man dann weitaus häufiger tun, verplempert also mehr Rechenzeit und
das bloß wegen eines popligen Drehgebers.
W.S.
W.S. schrieb:> Eine Ausnahme gibt es, nämlich Drehgeber. Die haben bei schnellem Drehen> eine für 10 ms Timertick zu hohe Datenrate
Dann nimmt man halt 5ms oder 1ms.
> und das zweite Signal des> Drehgebers (Richtung) muß zeitnah zum ersten Signal erfaßt werden.
Sofern die Signale auf dem gleichen IO-Port liegen, ist das trivial zu
machen.
> Deshalb ist bei Drehgebern eine Hardware-Entprellung und> Interruptbetrieb sinnvoll.
Entprellung in Hardware ist nur bei Wechslern gut machbar. Praktisch
alle mechanischen Encoder haben reine Schließerkontakte. Da muß man dann
lange Zeitkonstanten vorsehen, weil es ja auch nach 10.000
Betriebsstunden noch funktionieren soll, wenn alles etwas klappriger
geworden ist.
Außerdem ist gerade die enge zeitliche Abfrage beider Phasen im
Interruptbetrieb schlechter. Da liegt ja mindestens die
Interrupt-Latenz dazwischen.
> Natürlich kann man auch pollen, aber das> muß man dann weitaus häufiger tun, verplempert also mehr Rechenzeit
Selbst wenn der µC nur mit 1MHz läuft: der extra Aufwand für das Pollen
liegt vielleicht bei 20 Taktzyklen je 1ms. Also 2% der Rechenzeit. Das
ist doch Pillepalle.
W.S. schrieb:> und das zweite Signal des> Drehgebers (Richtung) muß zeitnah zum ersten Signal erfaßt werden.> Deshalb ist bei Drehgebern eine Hardware-Entprellung und> Interruptbetrieb sinnvoll.
Uff, du hast Drehgeber leider überhaupt nicht verstanden.
Na ja, kann ja noch kommen:
https://www.mikrocontroller.net/articles/Drehgeber
Obwohl, du hörst nicht das erste Mal von diesem Link.
Du MÖCHTEST also wohl dumm sterben.
Hans schrieb:> Wann fragt ihr wie einen pin ab?> Z.b. wenn ein Taster drann geschlossen ist?
Bei Tastern niemals via Pin-Change Interrupt, weil völlig unklar ist,
wie oft der aufgerufen wird (wenn der Taster prellt).
Axel S. schrieb:> Außerdem ist gerade die enge zeitliche Abfrage beider Phasen im> Interruptbetrieb schlechter. Da liegt ja mindestens die> Interrupt-Latenz dazwischen.
Naja, man kann ja im Interrupthandler beide Signale nochmal auslesen.
Wenn die Interrupt-Latenz so schlecht ist, dass das zu Problemen führt,
hast du ohnehin andere Probleme (denn dann ist dein Timer-Interrupt auch
betroffen).
Optimal ist natürlich eine in der Timerhardware integrierte
Drehgeberdecodiereinrichtung. Die schlägt sowohl Interrupt- als auch
Pollinglösungen... gibt's aber auf AVRs nicht.
Der tiefere Sinn hinter dieser Pin-Change-Interrupt-Sache ist die
Möglichkeit, viele Pins zu haben, über die man den Controller aus dem
Power-Down-Zustand aufwecken kann. Die Anwendung, wo man dieses Feature
braucht, sind Fernbedienungen. Da hat man viele (matrix-abgefragte)
Tasten und muss Power-Down nutzen, um Batteriestrom zu sparen.
Ohne PC-Interrupts könnte man dafür die externen Interrupt-Pins
verwenden, aber von denen gibt es nur einen oder zwei. Bei einer
Handvoll Tasten kann man noch mit Dioden tricksen, aber zwei Dutzend
oder noch mehr Tasten sind nur über eine Tastenmatrix ökonomisch zu
handlen (geringe Anzahl benötigter µC-Pins + einfaches Platinenlayout)
und dann scheidet diese Lösung aus.
Stefan ⛄ F. schrieb:> Bei Tastern niemals via Pin-Change Interrupt, weil völlig unklar ist,> wie oft der aufgerufen wird (wenn der Taster prellt).
Wenn du mit dieser Taste den µC wecken willst, wie geht das ohne
Interrupt?
Ich schrieb ja schon, wenn er wach ist, pollt man natürlich. Aber zum
Wecken?
Stefan ⛄ F. schrieb:> Bei Tastern niemals via Pin-Change Interrupt, weil völlig unklar ist,> wie oft der aufgerufen wird (wenn der Taster prellt).
Schreib doch nicht eine derart absolut klingende Antwort.
Gegenbeispiel: Ich hatte vor geraumer Zeit einen µC von Freescale vor
der Nase, der für seine Portpins eine _Hardware_-Entprellung eingebaut
hat. Irgend ein Kinetis.
Bei solchen hardwareseitigen Vorkehrungen hast du vom Programm aus ein
bereits entprelltes Signal und dein obiger Satz ist in solchen Fällen
eben falsch.
Ebenso falsch wäre er, wenn am Portpin ein bereits extern entprelltes
Signal vom besagten prellenden Taster anläge. Und fast immer reicht dazu
1x R/C und ein Schmittriggerverhalten des Portpins aus.
Axel S. schrieb:> Sofern die Signale auf dem gleichen IO-Port liegen, ist das trivial zu> machen.
Aber eben nur dann, wenn man entweder auf nen Interrupt reagiert oder in
recht kurzen Abständen pollt. Bei 10 ms muß man dem Benutzer sagen, daß
er nur vorsichtig und langsam dran drehen darf.
> Außerdem ist gerade die enge zeitliche Abfrage beider Phasen im> Interruptbetrieb schlechter. Da liegt ja mindestens die> Interrupt-Latenz dazwischen.
Hä?
Wovon redest du?
Ganz viele übliche DG haben Rastung und zumindest eines der Signal
ändert sich weitab von der Rastung. Das ist das Signal, was man entweder
pollt oder entprellt und nen Port-Change-Interrupt benutzt. Und das
andere Signal ist zum Zeitpunkt der Änderung des ersten stabil und
wird zeitnah erfaßt, um die Drehrichtung anzuzeigen. Wenn man zu lang
wartet (oder eben zeitlich zu weitab gepollt hat), dann merkt man zwar,
DASS sich was getan hat, aber weil das Richtungssignal sich inzwischen
geändert hat, verliert man dann eben die Richtung beim Pollen.
Michael B. schrieb:> Du MÖCHTEST also wohl dumm sterben.
Danke für die Blumen.
Mein Rat: werde hier nicht unsachlich und versuche erstmal einen der
heutzutage üblichen Drehgeber zu verstehen, bevor du hier dich daneben
benimmst.
So.
Uff.
Aus den gezeigten Beiträgen sieht man einmal wieder, daß es reinen
Programmierern immer wieder schwerfällt, sich analoge elektrische
Vorgänge wirklich vorzustellen.
Als Folge sieht man, daß entweder irgendwelche göttlichen Gebote
aufgestellt werden ("Du sollst NIEMALS dies oder jenes tun"), oder daß
Dinge einfach mißverstanden werden - und folglich fällt Softwareleuten
nichts ein, um an der richtigen Stelle die Dinge in Ordnung zu
bringen.
Die Folgen sieht man: einen popligen Drehgeber, der nur alle halbe
Stunde mal gedreht wird, soll man im 1 ms Takt pollen, bloß weil man zu
unfähig ist, dessen Prellen an der richtigen Stelle zu beseitigen.
Dabei sollten gerade Softwareleute das Allererste, was ihnen beigebracht
wird, besser erinnern: Hat man störbehaftete Signale, dann muß man sie
zuerst von den Störungen befreien, bevor man sie zum Erzielen von
Ergebnissen benutzt.
W.S.
Hans schrieb:> Pin immer pollen und sehen,> wann sich der Zustand geändert hat.> Letzteres hat den Vorteil, dass das Prellen abgefangen werden kann
Nein, das ist ein Nachteil.
Falk B. schrieb:> Und täglich grüßt das Murmeltier ;-)
Tja.
Das Problem ist, daß es logischemaßen zu allen Zeiten den Nachwuchs
gibt, der zwar wißbegierig ist, aber noch nichts gelernt hat. Und dem
muß man eben immer wieder die Dinge erklären.
jaja: ERKLÄREN! und nicht bloß ne eigene Dressur ("sowss MUSS SO UND
NICHT ANDERS gemacht werden") weitergeben.
Da sind die Einlassungen von Leuten, die in diesem Falle nicht
begreifen, wozu die Chiphersteller den Pin-Change-Interrupt in ihre
Chips eingebaut haben, schlichtweg nicht hilfreich.
W.S.
W.S. schrieb:> schlichtweg nicht hilfreich.
Ja, deine Beiträge sind so hahnebüchen, dass diese nicht hilfreich sind.
W.S. schrieb:> Schreib doch nicht eine derart absolut klingende Antwort.
Du bist lustig, wer schreibt denn hier sonst immer im Absoluten?
Zb bei der Verteufelung von DMA und Debuggern?
Hardwarefilter am Portpin sind aber eher selten (der Raspi hat auch
welche).
Wegen der Seltenheit ist ersteinmal abzuraten bis der Controllertyp
bekannt ist.
Wer noch RC Hardwareentprellung macht, dem ist nicht mehr zu helfen.
W.S. schrieb:> Aber eben nur dann, wenn man entweder auf nen Interrupt reagiert oder in> recht kurzen Abständen pollt. Bei 10 ms muß man dem Benutzer sagen, daß> er nur vorsichtig und langsam dran drehen darf.
Alle 1ms nen IRQ wäre aber auch kein Problem, selbst bei mehreren Ports.
Selbst bei vielen UART Baudraten ist die IRQ Last höher.
(Also wieso verteufelst du immernoch einen UART DMA wenn dir alles
weniger als 10ms zu viel IRQ Last für die CPU ist? Wie blöd bist du
eigentlich?)
W.S. schrieb:> Mein Rat: werde hier nicht unsachlich und versuche erstmal einen der> heutzutage üblichen Drehgeber zu verstehen, bevor du hier dich daneben> benimmst.
Mein rat: benimm dich erstmal selber im Forum oder wer beschimpft hier
andauernd Leute im Projekte UNterfprum wenn er nicht genauso schlecht
programmiert wie du?
Zusammenfassung:
Du bist der größte Dummschwätzer den das Forum je gesehen hat!
W.S. schrieb:> Axel S. schrieb:>> Sofern die Signale auf dem gleichen IO-Port liegen, ist das trivial zu>> machen.>> Aber eben nur dann, wenn man entweder auf nen Interrupt reagiert oder in> recht kurzen Abständen pollt. Bei 10 ms muß man dem Benutzer sagen, daß> er nur vorsichtig und langsam dran drehen darf.
Das ist doch albern. Wenn ich einen Drehgeber im Timer-Interrupt polle,
dann muß ich vorher mal überschlagen, wieviele Zustandswechsel der pro
Sekunde machen kann und dann lege ich das Timerintervall fest. Genauso
bin ich bei meinem Platinenbelichter auf 1ms gekommen.
>> Außerdem ist gerade die enge zeitliche Abfrage beider Phasen im>> Interruptbetrieb schlechter. Da liegt ja mindestens die>> Interrupt-Latenz dazwischen.>> Hä?> Wovon redest du?
Wovon redest du?
> Ganz viele übliche DG haben Rastung und zumindest eines der Signal> ändert sich weitab von der Rastung. Das ist das Signal, was man entweder> pollt oder entprellt und nen Port-Change-Interrupt benutzt. Und das> andere Signal ist zum Zeitpunkt der Änderung des ersten stabil und> wird zeitnah erfaßt, um die Drehrichtung anzuzeigen.
Ja. Eben. Du mußt es zeitnah abfragen. Wann du es abfragen mußt, sagt
dir aber der Interrupt. Der wird ja mit der Flanke des einen Signals
ausgelöst. Und erst in der ISR, einige Dutzend Takte später kannst du
das zweite Signal abfragen. Sie werden also gerade nicht gleichzeitig
abgetastet. Und das zusätzliche Abtasten des ersten Signals in der ISR
bringt auch nichts, weil das Ereignis ja die Flanke ist. Und die ist
lange vorbei, wenn die ISR angesprungen wird.
Wenn die Entprellung jetzt noch ein bißchen Verzögerung rein bringt und
der Interrupt vielleicht verspätet ausgeführt wird (die CPU war gerade
in einem ATOMIC_BLOCK) dann kann es schon zu spät sein. Und die tolle
Flankenmethode zählt den Impuls in der falschen Richtung.
Beim Pollen fragt man immer beide Signale gleichzeitig ab. In der
Timer-ISR. Das Ereignis (Zustandwechsel) kriegt man durch den Vergleich
mit den Werten vom letzten Mal raus.
> Die Folgen sieht man: einen popligen Drehgeber, der nur alle halbe> Stunde mal gedreht wird, soll man im 1 ms Takt pollen
Und was ist daran jetzt das Problem? Selbst auf einem sehr langsam
getakteten µC braucht man dafür nur 1 oder 2% CPU-Zeit. Kriegst du Geld
dafür, wenn der µC statt dessen in der Main-Loop herumidled?
Wenn der Drehgeber still steht, dann braucht man einen IO-Zugriff,
einmal das Ausmaskieren von 2 Bits, einen Vergleich und den bedingten
Sprung zum Ende der Auswertung. 20 Taktzyklen sind dafür sehr sehr
großzügig angesetzt.
