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.
:
Bearbeitet durch User
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).
Gerade in Frühjahr gibt es durch eine Pollen-Allergie bei vielen Menschen einen Interrupt, der eine Taschentuch-Serviceroutine beinhaltet.
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.
W.S. schrieb: > Deshalb ist bei Drehgebern eine Hardware-Entprellung und > Interruptbetrieb sinnvoll. Und täglich grüßt das Murmeltier ;-)
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.
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.