Moin, Gibt es eine Möglichkeit von mehr als zwei Tastern einen Interrupt auslösen zu lassen? Es gibt ja da zwei externe Interrupts, aber ich brauche drei Taster, die drei verschiedene Interrupts auslösen. Das müssen Interrupts sein, über eine Abfrage in einer Schleife geht das nicht. (PS:Wer meine letzte Frage hier in dem Forum gelesen hat, ich habe einen neuen 78S05 gekauft, hält zwei Ampere aus und jetzt funktioniert alles einwandfrei. Liegt aber nicht am Strom, irgendwie war der alte 7805 kaputt. Weiß nur nicht, ob der von Anfang an kaputt war, oder ob das meine Dummheit war.)
Du könntest die beiden über Dioden an einen Externen Interrupt-Eingang hängen. Dann könntest du zumindest den Controller wecken. Allgemein fragt man Taster in regelmässigen Abständen (zig Millisekunden) ab und entprellt sie auch auf diese Weise...
Welcher micro denn? Es gibt oft CounterEingaenge, die auch als Int benuetzt werden koennen. Robert
Tschuldigung, schon wieder den Typ vergessen. Ist ein ATMega8. Wie soll das mit den Dioden gehen? Die Interrupts werden bei laufendem Controller ausgeführt, dienen nicht dazu den Controller wieder aus dem Ruhezustand zurückzuholen
>Das müssen Interrupts sein, über eine Abfrage in einer Schleife geht das >nicht. Warum geht das nicht? Eigentlich geht das immer. Ansonsten: Jede Taste auf den externen Interrupt, sowie auf einen eigenen Portpin parallelschalten, und den Port in der ISR auswerten. Soviel Zeit muß sein. Oliver
So einfach, wieso bin ich da nicht selbst drauf gekommen? Danke
Dussel wrote: > Gibt es eine Möglichkeit von mehr als zwei Tastern einen Interrupt > auslösen zu lassen? Es gibt ja da zwei externe Interrupts, aber ich > brauche drei Taster, die drei verschiedene Interrupts auslösen. Das > müssen Interrupts sein, über eine Abfrage in einer Schleife geht das > nicht. Und wo ist das Problem ? Wenn die MC-Entwickler der Meinung währen, externe Interrupts sind gut geeignet um Tasten zu entprellen, dann hätten sie auch mehr davon eingebaut. Anders gesagt, sie sind es nicht. Nimm besser nen Timerinterrupt für egal wieviel Tasten. Schau einfach mal in die Codesammlung. Peter
Taster sollten den µC über Interrupt wecken bzw. die Interrupt-Routine starten. Dass man danach mit Timern entprellen kann/muss, ist klar. Es gibt viele Anwendungen, in denen der µC schläft und nur auf eine Taste (oder was anderes) wartet. Da wird man doch nicht polling machen. Beispiel Taschenrechner - da macht jede Taste einen Interrupt. Klar - polling geht immer. Man kann auch Timing mit Verzögerungsschleifen machen. Aber dafür sind die Interrupts ja da. Eigentlich ist unser ganzes Leben interruptgesteuert (=externe Ereignisse). Wir gucken ja auch nicht alle 30 Sekunden an der Tür, ob da jemand ist... So jetzt könnt ihr darüber ablästern.
@ Peter Dannegger: Selbstverständlich sind INTs zum erkennen von Tastendrücken (?) da! Die Entwickler haben sich dabei schon was gedacht, nämlich dass beliebig viele Tasten (Kontakte) den INT auslösen können, wie oben schon gesagt: Diodenentkoppelt. Die Auswertung der Tasten (Kontakte) und die Entprellung macht man nach ausgelöstem INT per Timer-INT und gesperrtem Tasten-INT. Das ermöglicht einen Sleep-Mode des µC und kostet keine Polling-Zeit.
Tom wrote: > Es gibt viele Anwendungen, in denen der µC schläft und nur auf eine > Taste (oder was anderes) wartet. Da wird man doch nicht polling machen. > Beispiel Taschenrechner - da macht jede Taste einen Interrupt. Nö. Nur die Einschalttaste hängt mit am Interrupt, alle anderen nicht. Gäbe auch keinen Sinn, solange Du nichts drückst, hat er doch nichts zu tun. > Klar - polling geht immer. Bei Matrixanordnung geht sogar nur Polling, anders ließen sich Tastenkombinationen (Ctrl+Alt+Del) nicht erkennen. Peter
Power wrote: > Selbstverständlich sind INTs zum erkennen von Tastendrücken (?) da! Die > Entwickler haben sich dabei schon was gedacht, nämlich dass beliebig > viele Tasten (Kontakte) den INT auslösen können, wie oben schon gesagt: > Diodenentkoppelt. Komisch, ich habe zwar schon oft Tasten an MCs gesehen, aber noch nie mit Dioden. Bei Fernbedienungen nimmt man den Pin-Change-Interrupt nur zum Aufwecken und danach pollt man die Matrix. Peter
>Bei Fernbedienungen nimmt man den Pin-Change-Interrupt nur zum Aufwecken >und danach pollt man die Matrix. Ist bei meinen Fernbedienungen auch so ;-).
Hi, also ich mache das auch immmer mit Dioden. Ich frage z.B. ein kompletten Port mit einem einzigen Interrupt ab. 8 Schalter an ein Port und jeden einzelen Port dann noch mal über eine Diode auf EINEN Interrupt. In der Inerruptroutine frage ich dann erst ab welcher Pin sich geändert hat. Für Zeitunktische Anwendungen geht das ohne Probleme!! Grüße, Marcel
Die TasterAnInterrupt-Fraktion stirbt einfach nicht aus... Ich habe auch langsam keine Lust mehr, dagegen zu argumentieren. ...
Wenn Du alle 8 Taster mit einem Pin an den Interruptpin hängst, diesen mit einem Pullup auf Vcc ziehst und alle anderen Tasterpins an einen Port hängst, dann brauchst Du keine Dioden. Die einzelnen Portpins werden nacheinander auf Low-Level geschaltet. Die sieben anderen sind dabei hochohmig (Eingang ohne PullUp). Der Interrupt kommt, wenn ein Taster den Low-Level an den Interrupt-Pin weiterleitet. Da der Controller weiß, welcher Portpin gerade Low-Level hat, weiß er auch in der ISR auch gleich, welche Taste gedrückt war. Wenn man den Interrupt nur zum Wechen braucht, schaltet man vor dem "sleep" alle Tasten-Portpins auf Low. Dann können alle Tasten den "Weck-Interrupt" auslösen. Anschließend schaltet man auf Timergestütztes Polling um, wobei das Entprellen auch gleich miterledigt wird. Außer den Tastern braucht man keine externen Bauelemente.
@Hannes: locker bleiben! ;-)
Es gibt mit ein paar Tricks auch mehr als zwei externe interupts am Mega8 Nur können diese den AVR nicht aus jedem Schlafzustand herrausholen. Ich nehme zum Beispiel gerne den Analog Comparator Interrupt gerne als dritten Interrupt beim Mega8. Der Eingangspin hierfür wäre dann AIN1(PD7) Für die Referenzspannung kann man die Bandgap Reference nehmen. Wenn das noch nicht reichen sollte, dann kan man auch den Input Capture Pin (PB0) als vierten externen Interrupt nehmen. Ist zwar alles nicht so wie sich die Chip designer sich das vorgestellt haben, aber was solls. Aus meiner Erfahrung kann ich sagen, daß es funktioniert. cu Hauke
>Bei Fernbedienungen nimmt man den Pin-Change-Interrupt nur zum Aufwecken >und danach pollt man die Matrix. Polling ist zyklischen Abfragen der Taster im Hauptprogramm ohne Interrupt. Bei der Fernbedienung wird nach dem Interrupt jede Taste einmal abgecheckt, das ist nicht polling. >Die TasterAnInterrupt-Fraktion stirbt einfach nicht aus... Schreib mal ein Programm, welches mehrere Taster pollt, und noch eine Delayschleife benutzt. Dann vielleicht noch beim ADC und UART vorbeigucken, und dann soll das Timing noch präzise sein? Die GOTO-Fraktion ist auch schon tot.
> und noch eine Delayschleife benutzt. Delay-Schleifen benutzt man ja auch nicht! Du gehörst anscheinend zur "AllesMitDelaySchleifenMachenWollen"-Fraktion... > Die GOTO-Fraktion ist auch schon tot. Leider nein. Siehe Beitrag "Hilfe beim Sleep-Mode"
Tom wrote: > Polling ist zyklischen Abfragen der Taster im Hauptprogramm ohne > Interrupt. Wer hat denn festgelegt, daß Polling nur im Main erlaubt ist ? Ich polle meistens im Timerinterrupt. Das ist sogar richtiges "zyklisches Abfragen" und nicht rein zufällig von der Main-Durchlaufzeit abhängig. Peter
>Polling ist zyklischen Abfragen der Taster im Hauptprogramm ohne >Interrupt. Son Quatsch. Natürlich darf man in einer Timer-ISR den Zustand der Eingänge abfragen. Damit benutzt man einen Interrupt und Polling... >Bei der Fernbedienung wird nach dem Interrupt jede Taste einmal >abgecheckt, das ist nicht polling. Ist es wohl. Ob man es "abchecken" oder "abfragen" nennt ist dabei egal. Polling bedeutet, dass der Zustand vom Programm (also der Software) abgefragt wird. Bei einem Interrupt liefert die Hardware eine Adresse zu der das Programm verzweigt wird (sofern der Interrupt zugelassen wird). >Schreib mal ein Programm, welches mehrere Taster pollt, und noch eine >Delayschleife benutzt. Dann vielleicht noch beim ADC und UART >vorbeigucken, und dann soll das Timing noch präzise sein? Wer eine Delayschleife zur Entprellung benutzt, benutzt vermutlich auch GOTO... Guck dir die Tastenentprellung von Peter Dannegger in der Codesammlung an. Da wirst du sehen, dass man weder ein externen Interrupt, noch eine Delayschleife braucht. @Hannes: ... Windmühlen...
>> Bei der Fernbedienung wird nach dem Interrupt jede Taste einmal >> abgecheckt, das ist nicht polling. > Ist es wohl. Ob man es "abchecken" oder "abfragen" nennt ist dabei egal. > Polling bedeutet, dass der Zustand vom Programm (also der Software) > abgefragt wird. Kann ich nur zustimmen. Polling bedeutet einfach nur eine softwaremäßige Abfrage, sonst nix. Polling muss nicht zyklisch sein. Es bedeutet lediglich (im Unterschied zur Interrupt-gesteuerten Verarbeitung), dass das Programm selber nachsehen muss, was da abgeht und nicht von der Hardware darauf aufmerksam gemacht wird.
> Guck dir die Tastenentprellung von Peter Dannegger in der Codesammlung > an. Da wirst du sehen, dass man weder ein externen Interrupt, noch eine > Delayschleife braucht. Das ist ja das Problem. Peters Code (nicht nur der, auch die anderen) ist meist so hochkomplex, dass man als Anfänger kaum eine Chance hat, ihn zu verstehen. Und es soll Leute geben, die alles, was sie nicht verstehen, als Quatsch abtun. Ehe wieder Kontra kommt: Ich meide in meinen Programmen auch Code, den ich (noch) nicht verstehe, mache ihn aber nicht öffentlich nieder. ...
Wer keine Lust auf Timerinterrupts mit dortiger Abfrage(Polling?) der Tasten und auch keine alternativen Dioden mag, der moege seinen Mega8 einfach wegschmeissen und sich einen Mega48/88/168 zulegen. Bei dem ist auf so ziemlich jedem Pin ein Pin-Change Interrupt moeglich. cu Tarzanwiejane
Zitat "Dussel": "Das müssen Interrupts sein, über eine Abfrage in einer Schleife geht das nicht." Ohne genaue Vorlage des Projekts ist natürlich davon auszugehen das es sich um Tastenentprellung handelt. Nur gibt's da auch andere Dinge, wie z.B. extern getriggerte Counter o.ä. Allerdings wenn eine solche Anwendung z.B. nur einige kHz Abtastfrequenz benötigt reicht Timer-Overflow polling mehr als aus. Und wie schon erwähnt reicht ein IRQ aus um mehrere Ereignisse abzufragen, es muß halt nur in der ISR geguckt werden welcher Wert sich geändert hat. So lassen sich sogar acht Werte "gleichzeitig" erfassen ;-)
Man lese auch die zweite Zeile des Eröffnungsbeitrags. Da ist eindeutig von Tastern die Rede. Somit sind Deine (ansonsten berechtigte) Bedenken bezüglich schnellerer Signale (mehrere kHz) gegenstandslos. ;-) ...
> Kann ich nur zustimmen. Polling bedeutet einfach nur eine softwaremäßige > Abfrage, sonst nix. Polling muss nicht zyklisch sein. Hier scheint ein bisschen Unklarheit zu herrschen, was Polling ist: Polling bezeichnet in der Informatik die Methode, den Status von bestimmter Hard- oder Software mittels zyklischem Abfragen zu ermitteln. aus: http://de.wikipedia.org/wiki/Polling_%28Informatik%29 Man beachte das Wort "zyklisch".
Hmm.. mir scheint, die 'Taster-MUSS-man-per-Pollig-Abfragen' - Lobby hat sich hier wieder formiert! Leute, akzeptiert es doch endlich dass es auch anders geht! Ist doch jedem selber überlassen wie er da realisieren will, oder? Ich mache das mittlerweile mal so und mal so, manchmal auch kombiniert. Einige hier haben eine andere Bedeutung von 'Polling' im Kopf, nämlich das zyklische Abfragen in der 'main'. Das war auch mal DAFÜR die Bezeichnung. Das 'Abscannen' einer Matrix in einem INT würde ich nicht als Polling bezeichnen, da es kein endloses Abfragen ist, was mit Pollig eigentlich mal gemeint war.
Power wrote: > Das 'Abscannen' einer Matrix in einem INT würde ich nicht > als Polling bezeichnen, da es kein endloses Abfragen ist, was mit Pollig > eigentlich mal gemeint war. Deshalb vermeide ich auch den Begriff Polling und rede von zyklischem Abfragen. Ob dies im Timer-Interrupt passiert oder in einem Job der Mainloop, der vom Timer (oder einem anderen taktgebenden, also zyklisch auftretenden Ereignis wie dem Servoimpuls einer RC-Fernsteuerung alle 20 ms) synchronisiert wird, steht dabei auf einem anderen Blatt. Zumindest frage ich einen Taster nicht in einer Warteschleife ab, die nur den Eingang prüft und erst verlassen wird, wenn der Taster betätigt wird. Das würde ich nämlich auch unter Polling verstehen (so wie Polling eines Busy-Flags). Die Abfrage erfolgt immer so, dass sie "nebenbei" erfolgt, der Controller dabei niemals warten muss. Das Erkennen von Tastendrücken mittels Pin-Interrupt (egal ob intX oder pcintX) erfordert zur Störunterdrückung eine Entprellung. Dazu wird gern eine "Warteschleife" eingefügt (in die ISR natürlich). Diese Art Programme mögen ja halbwegs funktionieren, sind aber nicht mein Stil. Ganz Schlaue starten dann vielleicht einen Timer (für diesen einen Entprellvorgang), da wird meist die Soße teurer als der Braten. Dagegen bringt die Abfrage der Taster (meist sind es ja mehrere) im (sowiso vorhandenen) Timer-Interrupt nur Vorteile. Die eigentliche Routine braucht nur wenige Takte, als Ergebnis stehen für jeden Taster mehrere Bits zur Verfügung, die das Hauptprogramm in aller Ruhe (bei Gelegenheit) auswerten kann: - Key_state zeigt den entprellten Zustand des Tasters an - Key_press zeigt an, dass der Taster neu gedrückt wurde - Key_lost (falls implementiert) zeigt an, dass der Taster losgelassen wurde - mit Key_repeat_count und drei Konstanten (Maske auf Repeat-Tasten, Zeitdauer bis zur ersten Wiederholung, Wiederholtempo) lässt sich der Dauerdruck ausgewählter Taster erkennen und darauf reagieren. Soll der Dauerdruck dieselbe Aktion auslösen wie der Einzeldruck (nur immer wieder hintereinander), dann setzt man damit Key_press erneut. Soll der Dauerdruck andere Aktionen auslösen, setzt man damit eben Bits in einem anderen Register, z.B. Key_repeat. Die Routine braucht je nach Ausstattung 11 bis um die 20 Takte alle 4 bis 20 Millisekunden und liefert auch mit labrigen Tastern präzise Ergebnisse. Dabei wird ein Tastendruck (eigentlich eine Tastenveränderung, denn das Loslassen wird ja auch entprellt), also der Pegel am Eingangspin, nur übernommen, wenn er bei vier aufeinander folgenden "Abfragerunden" unverändert angelegen hat. Diese Sicherheit bieten die Interrupt-Entprellungen nunmal nicht. Ein Low-Level-Interrupt (oder PCI) kann sehr nützlich sein, um den Controller aus dem stromsparenden Tiefschlaf zu wecken, aber das eigentliche Entprellen der Taster würde ich damit nicht machen wollen, das ist mit zyklischer Abfrage bedeutend billiger und komfortabler zu haben. Soviel zur 'Taster-MUSS-man-per-Pollig-Abfragen' - Lobby ...
Schönes Referat. ;-) Trotzdem mache ich das auch per INT wenn es günstiger ist. Das muss von Fall zu Fall abgewägt werden.
>Trotzdem mache ich das auch per INT wenn es günstiger ist. Das muss von >Fall zu Fall abgewägt werden. Mach wie du willst. Einfacher finde ich es, die Tasterentprellroutine aus meiner Sammlung zu benutzen. Da man zum Entprellen immer eine "Wartezeit" braucht, ist die Timervariante für mich die einfachste...
>Da man zum Entprellen immer eine "Wartezeit" braucht, ist die Timervariante für
mich die einfachste...
Genau da kommt die Kombination zum Tragen.
Da der µC bei Tastendruck 'aufgeweckt' wird, wird die (hier schon so oft
gepriesene) Zeitbasis, z.B. ms-Timer-INT gestartet, bzw. benutzt, und
diese zum Entprellen verwendet.
Für Stromsparlösungen ist diese Methode auf jeden Fall vorzuziehen, als
ständig die Zeitbasis laufen zu lassen. Kostet zwar u.U. einen Timer,
der Zweck der Schaltung ist dafür erfüllt.
Mal nachgefragt: für was ist deiner Meinung nach der INT0 und INT1
vorgesehen? Scheinbar ist der nach euren Aussagen zu nichts zu
gebrauchen?! ;-)
Power wrote: > Mal nachgefragt: für was ist deiner Meinung nach der INT0 und INT1 > vorgesehen? Scheinbar ist der nach euren Aussagen zu nichts zu > gebrauchen?! ;-) Nö, die sind sehr gut geeignet, um externe Peripherie-Chips anzuschließen, z.B.: SJA1000, LAN91C96, MCP2515, ENC28J60, PCF8574. Gerade bei Peripherie mit I2C- oder SPI-Anbindung spart ein Interruptpin Zeit. Und z.B. CAN mit 1MBit ist gegenüber dem schneckenlahmen Menschen Warp-schnell, da bringt ein Interrupt auch wirklich Punkte. Peter
Eigentlich wollte ich mich nicht mehr dazu äußern, aber ich lasse mir nicht gern das Wort im Munde herumdrehen. ;-) Power wrote: >>Da man zum Entprellen immer eine "Wartezeit" braucht, ist die Timervariante für mich die einfachste... > > Genau da kommt die Kombination zum Tragen. > Da der µC bei Tastendruck 'aufgeweckt' wird, wird die (hier schon so oft > gepriesene) Zeitbasis, z.B. ms-Timer-INT gestartet, bzw. benutzt, und > diese zum Entprellen verwendet. Ja richtig, was Anderes habe ich ja nicht behauptet, zumindest nicht für den Fall, dass der AVR aus dem (stromsparenden) "Tiefschlaf" geweckt werden soll. Der Interrupt weckt auf, der Timer bekommt Takt und fängt an zu klappern, die Timer-ISR entprellt die Taster und filtert damit Störungen, die zum Aufwecken geführt haben könnten, aus. > Für Stromsparlösungen ist diese Methode auf jeden Fall vorzuziehen, als > ständig die Zeitbasis laufen zu lassen. Das habe ich nie bestritten! Aber nach dem Aufwecken ist die zyklische Abfrage im Timer-Int immernoch die bessere Methode. Während des "Tiefschlafs" klappert natürlich kein Timer, das wäre Stromverschwendung. > Kostet zwar u.U. einen Timer, Aber keinen zusätzlichen. Der wird meist für viele andere Dinge als Zeitbasis gebraucht, die Entprellung macht er ganz nebenbei. > der Zweck der Schaltung ist dafür erfüllt. Der Zweck ist das Aufwecken. > > Mal nachgefragt: für was ist deiner Meinung nach der INT0 und INT1 > vorgesehen? Da gibt es viele Verwendungsmöglichkeiten, es sollten aber prellfreie Signale sein. Z.B. elektronisch erzeugte Impulse. Mechanische (prellende) Schaltelemente gehören aber nur im Notfall dazu, z.B. zu, Aufwecken. > Scheinbar ist der nach euren Aussagen zu nichts zu > gebrauchen?! ;-) Doch, nur nicht zum Entprellen von Tastern und Schaltern, das geht anders besser, komfortabler und billiger. ...
Wenn man mehr externe Interupt fähige Eingänge benötigt als der µC hergibt, dann sollte man mal drüber nachdenken, ob man den richtigen µC ausgewählt hat. Man kann natürlich mit vielen Tricks das ganze irgendwie zum laufen bringen, aber ist das der richtige Weg ? Für die Bastler mag das der richtige Weg sein, "auf eigene Schulter klopfen und wie gut ich doch wieder bin" Nur Zielführend ist es nicht. Der Weg muss sein : 1. Was will ich machen 2. Was muss ich haben, machen damit ich das Ziel von 1. erreichen kann 3. Welche Komponenten erfüllen meine Anforderungen aus 2. 4. und jetzt kann man mit der Implementierung anfangen. Wer mit Punkt 4 anfängt macht viele Umwege. Das gleiche ist es auch mit der Auswahl der Programmiersprache. Da wo es notwendig ist, passt Assembler sehr gut. ( zb Spezeille Registerzugriffe bei einzelnene µC) Für alle anderen Fälle steht der Aufwand der Assemblerprogrammierung in keinem vernünftigen Verhältnis zum Ergebnis. Ich will jetzt keinem der in Assembler programmiert sagen das er was falschen macht. Ich hab hochachtung vor jemandem der ein komplexes Programm in Assembler erstellen kann. Aber wenn er dann mal einen anderen µC benutzen muss, kann er den Code wegwerfen und von vorne beginnen. Ist das ganze in C programmiert, nimmt man den passenden Compiler, muss nur die Defines für Register, Ports,... ändern und der Code läuft. Die Zeitersparnis ist gewaltig. Von der Nachvollziehbarkeit nach einigen Monaten will ich da gar nicht erst reden. Zusammengefasst: Erst das ganze Projekt durchdenken und dann die passende Hardware aussuchen.
@ Hannes:
>Eigentlich wollte ich mich nicht mehr dazu äußern
Dann lass es.
Du bist zu Eingeschossen auf deine Variante. ;-(
Power: Du solltest lieber ein wenig die Füße still halten. Es gibt Leute, die immmer und ständig anderen Leuten Vorschriften machen müssen, nur damit sie etwas vorzuweisen haben, womit sie andere beeindrucken können. Hannes gehört nicht dazu - ich kenne ihn als sehr konstruktiven und hilfsbereiten Mitstreiter hier im Forum. Wenn Du Dir die Mühe machst, seine Projekte anzuschauen, dann merkst Du auch, daß er was vom Programmieren versteht. Du mußt seine Vorschlage nicht annehmen und kannst machen, was Du willst, aber mach ihn hier nicht ´runter! @Hannes: Laß´ Dich nicht ärgern! Meine Zustimmung zu Deiner Variante hast Du - ich weiß aus Erfahrung, daß es anders zwar auch geht, aber viel anfälliger ist. Interrupt zum Wecken muß sein, zum Tastenabfragen ist er jedoch viel zu sensibel und bringt das Programm durcheinander - alles natürlich eine Sache des direkten Anwendugszwecks. In zuverlässigen und komplexeren Anwendungen hat eine Taste, die direkt einen Programmsprung verursacht, meiner Meinung nach, nur Nachteile. Grüße nach MD!
@ Travel rec:
>Du mußt seine Vorschlage nicht annehmen und kannst machen, was Du willst, aber
mach ihn hier nicht ´runter!
Mache ich nicht. Ich appeliere lediglich an seine Toleranz, auch andere
Lösungswege zu akzeptieren.
Sein Fachwissen und seine Programmierfähigkeiten stelle ich keineswegs
in Frage, das hat er schon oft genug bewiesen.
Und um konstruktive Kritk auszuschalten solltest du anderen nicht
empfehlen die Füße still zu halten, das werde ich ganz sicher nicht tun!
Auch nicht dir gegenüber.
Naja - ich finde nur, daß Du ziemlich große Töne spuckst und trotzdem auf "Lösungen" beharrst, die sich als unpraktikabel erwiesen haben. Wenn jetzt Leute, die noch nicht so viel Erfahrung haben, auf die Interrupt-Variante setzen und sich dann immer wundern, warum ihr Programm ein Eigenleben entwickelt, ist doch auch keinem geholfen. Interrupts sind - meines Erachtens - wirklich nur dazu gedacht, den eigentlichen Programmablauf kurzzeitig unbedingt zu unterbrechen, um zeitkritische Signale zu erfassen und abzulegen, damit eine spätere Abarbeitung im Hauptprogramm die notwendigen Änderungen ausführen kann. Ich möchte nicht, daß mein Programm unvermittelt 5-20 mal von einem einzigen Tastendruck unterbochen und in seiner Arbeit behindert wird, obgleich selbige Funktionalität nebenbei erledigt werden könnte und keinerlei merkliche Timingvariationen entstehen würden, egal ob nun (wild) an den Tasten gespielt wird, oder nicht. In Systemen, die den Controller anderweitig beschäftigen, hat er für so popelige Tastenabfragen, die ihn von der Arbeit abhalten, auch gar keine Zeit.
>Ich appeliere lediglich an seine Toleranz, auch andere >Lösungswege zu akzeptieren. Warum sollte er den Lösungsweg nicht akzeptieren, wenn es auf das Gleiche hinausläuft: Einen Taster (oder anderen mechanischen Schaltkontakt) hägnt man an einen Interrupt-Pin, wenn man den Controller aus dem Tiefschalf wecken will. Wenn man den Controller gar nicht schlafen schickt, braucht man auch keinen Interrupt-Pin, um ihn zu wecken. Einen Timer zum Entprellen aber schon...(sogar deine Aussage). PeDa hat ja schon sinnvolle Anwendungen für externe Ints aufgezeigt: Elektronische Periferie!
Nunja, der INT sollte nach erkanntem Tastendruck ja auch gesperrt werden, dann kommt die Entprellung (per Timer-INT) oder der Matrix-Scan. Erst wenn wieder auf Tastendruck reagiert werden soll wird der INT wieder freigegeben. Kommt natürlich immer auf die Schaltung und das Programm an, ob das praktikabel ist oder nicht. Ich habe das in vielen Schaltungen schon so realisiert und es läuft problemlos. Wie gesagt: es führt nicht immer nur ein Weg ans Ziel, es sollte eben der günstigste gewählt werden.
> Nunja, der INT sollte nach erkanntem Tastendruck ja auch gesperrt > werden, dann kommt die Entprellung (per Timer-INT) oder der Matrix-Scan. Achnee, jetzt also doch? Das ist ja genau das, wes ich die ganze Zeit empfehle. > Erst wenn wieder auf Tastendruck reagiert werden soll wird der INT > wieder freigegeben. Diese Kleinigkeit mach' ich etwas anders: Erst wenn der Controller nix mehr zu tun hat, alle seine Arbeiten also erledigt sind, der Benutzer also vorerst das "Gerät" nicht mehr braucht, dann wird vom Sleep-Mode Idle auf den Sleep-Mode Power-Down umgeschaltet und der Tasten-Int aktiviert, damit der Benutzer das Ding wieder einschalten bzw. aufwecken kann. Für das Erkennen weiterer Tastendrücke bei "laufendem Gerät" schalte ich den externen Int für Taste nicht ein, der stört nur unnötig den Programmablauf. Und wenn das Gerät nicht batteriebetrieben ist, hat das Ganze überhaupt keinen Sinn, es ist lediglich eine Stromsparmaßnahme. > Wie gesagt: es führt nicht immer nur ein Weg ans Ziel, es sollte eben > der günstigste gewählt werden. Eben, nur deshalb habe ich meine Meinung geäußert. Übrigens: Die Art der Tastenabfrage, die ich nutze (und empfehle), ist nicht "meine Erfindung", sondern beruht auf PeDas Bulletproof-Entprellung (siehe Codesammlung). Und ich habe kein Problem damit, in meinen Quelltexten auf den Urheber zu verweisen. ...
Boah, was habe ich hier für eine Diskussion losgetreten... Habe nochmal nachgedacht und bin zu dem Schluss gekommen, dass ich es so hinbiegen kann, dass ich einen Taster in einer Schleife abfrage und den anderen durch ein Pedal ersetze. So dürfte es dannn keine Probleme mehr geben, hoffe ich.
>es ist lediglich eine Stromsparmaßnahme Nicht nur! Wenn ich per Tastendruck einen laufenden Prozess unterbrechen will der viele Interrups bekommt kann es sein, dass noch einige INTs unberechtigt abgearbeitet werden, da der Timer-INT eine niedrigere Prioritaet hat. Bei STOP-Tasten kann das notwendig sein. >ist nicht "meine Erfindung" Schon klar, man wird hier nur sehr schnell gemassregelt und in die Ecke gestellt wenn man mal einen Anderen Weg Zeigt und eine andere Meinung hat! (wieso habe ich auf einmal den Ami-Tastaturtreiber drin, liegt das an der Seite?)
@Power Sorry wenn ich dich korrigiere. Aber der AVR besitzt keine Interrupt Prioritäten. Es gilt einfach wer zuerst kommt malt zuerst. Nur wenn Interrupts zum exakt gleichen Taktzyklus auftreten dann werden diese nach der Reihenfolge der Interruptvektoren abgearbeitet. Dies kann passieren, wenn während das I-Flag nicht gesetzt ist (cli oder bei der Ausführung einer ISR) zwei neue Interruptereignisse (mit unterschiedlichen Vektoren) eintreten. Nach dem Setzen des I-Flag (sei oder reti) werden die ausstehenden Interrupts dann nach o.g. Reihenfolge abgearbeitet. cu Hauke
Power wrote: >>es ist lediglich eine Stromsparmaßnahme > Nicht nur! Wenn ich per Tastendruck einen laufenden Prozess unterbrechen > will der viele Interrups bekommt kann es sein, dass noch einige INTs > unberechtigt abgearbeitet werden, Wenn das Szenario zutreffen sollte, dann hat man bei der Programmierung verdammt viel falsch gemacht! > da der Timer-INT eine niedrigere > Prioritaet hat. Bei STOP-Tasten kann das notwendig sein. Siehe Hauke... > >>ist nicht "meine Erfindung" > Schon klar, man wird hier nur sehr schnell gemassregelt und in die Ecke > gestellt wenn man mal einen Anderen Weg Zeigt und eine andere Meinung > hat! Es ist nicht Deine andere Meinung, sondern Deine Intoleranz Anderen gegenüber, die man mit etwas Bosheit als Selbstüberschätzung auslegen könnte (was ich aber nicht tu'). Ich weiß weißgott auch nicht alles, bin aber bereit, dazuzulernen. > > (wieso habe ich auf einmal den Ami-Tastaturtreiber drin, liegt das an > der Seite?) Ich war's!!! - Und jetzt ist Frieden... ;-) ...
@ Hauke: >Es gilt einfach wer zuerst kommt malt zuerst. >Nur wenn Interrupts zum exakt gleichen Taktzyklus auftreten dann werden >diese nach der Reihenfolge der Interruptvektoren abgearbeitet. Nein. Wenn währen der Abarbeitung des INT0 (erster Vektor in der INT-Vektorenliste) das INT0-Flag erneut gesetzt wird, wird diese Liste erneut von oben abgearbeitet. Dadurch wird der zweite Vektor nicht erreicht, erst wenn das INT0-Flag nicht mehr gesetzt ist wird der nächste INT abgearbeitet. klar ist das keine Priorität im althergebrachten Sinn, wirkt sich aber ähnlich aus. >bin aber bereit, dazuzulernen. Ich auch. Habe auch schon von dir dazugelernt, so intolerant bin ich nu auch wieder nicht. ;) >Ich war's!!! - Und jetzt ist Frieden... Wusst' ich's doch! ;-)
Du sagst es. Es ist eine keine PRIORITÄT!!! Es ist schlichtweg eine Reihenfolge der Abarbeitung. Der AVR kennt was Interrupts angeht nur zwei Zustände. Entweder Interrupts sind erlaubt (I-Flag gesetzt). Oder Interrupts sind NICHT erlaubt (I-Flag gelöscht). Interrupt-Prioretisierung (wird das wirklich so geschrieben???) meint, daß ein Interrupt einer hohen Priorität die ISR eines Interrupts mit niedrieger Priorität unterbrechen kann. (aber nicht umgekehrt) Also: Main wird von ISR(lp) unterbrochen. ISR(lp) wird danach von ISR(HP) unterbrochen. ISR(HP) wird abgearbeitet. ISR(lp) wird ab der Stelle der Unterbrechung durch ISR(HP) weitergeführt. Main wird ab der Stelle der Unterbrechung ISR(lp) weitergeführt. Um eine ISR im AVR unterbrechen zu lassen, müßte man das I-Flag wieder setzen. Jedoch finde ich, daß SEI in einer ISR nichts zu suchen hat. Sowas führt schnell zu einem Stacküberlauf. Eine andere Sache ist natürlich wenn deine ISR den Grund des Interrupts nicht behebt. Dann ist üblicherweise etwas im Programmdesign grundsätzlich falsch. (Dein AVR wird die ISR nicht wieder verlassen können) Es ist auch dann etwas faul, wenn der Interrupt schneller und öfter kommt als deine ISR ihn abarbeiten kann. Dein AVR bleibt in der ISR und kann sein eigendliches Hauptprogramm und andere Interrupts nicht mehr abarbeiten. Besser ist es wenn man nach einem Interrupt "Taste wurde gedrückt" ein Flag in einem Register setzt und den Interrupt-Trigger danach auf "Taste wurde losgelassen" stellt. cu Hauke
Ja, mit deiner 'Interrupt-Prioretisierung' hast du natürlich Recht. Wenn das 'I'-Flag in der ISR wieder gesetzt wird sollte man genau wissen was man macht, ist aber wirklich nicht zu empfehlen sowas zu machen. Ich hatte das Problem des Prellens mal mit einem Thermostatprüfgerät (Visualisierung, einfacher wechsler). Der Thermostat hat so besch.. Kontakte gehabt und hat so langsam geschaltet dass er sekundenlang geprellt hat. In dem Fall kamen die Impulse im µs-Bereich, da hätte es definitiv Probleme gegeben. Darum lösche ich das entsprechende INT-Flag bevor ich ihn wieder 'scharf' schalte.
> Interrupt-Prioretisierung (wird das wirklich so geschrieben???)...
"Priorisierung"
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.