Weil Tasten nun mal prellen.Zitat von frabe
Weil man bei Tasten auf Drücken und Loslassen üblicherweise unterschiedlich reagiert. Das chPINA zeigt beides an. Auch auf PCs findest Du genau diese vom Betriebssystem bereitgestellten Funktionen KeyDown()/KeyUp(). Warum also das Rad neu erfinden?
Erst einmal vielen Dank für eure Mühe!
Folgenden Code finde ich sehr einfach und übersichtlich.
Bei "volatile uint8_t RegA_akt = PINA" hat der Compiler gemeckert, daher den Umweg über InitKeys().
Tastenentprellung ist noch nicht drin.
@Holomino, deine Tastenentprellung habe ich noch nicht in Gänze verstanden.Code:volatile uint8_t RegA_akt; // übergeordnete Variable void InitKeys(void) { RegA_akt = PINA; // aktuelles Register A wird gespeichert } ISR (PCINT0_vect) // Interrupt, aus Bank0, wird ausgelöst { uint8_t Auswahl = 0; uint8_t RegA_neu = PINA; uint8_t RegA_diff = RegA_akt ^ RegA_neu; // veränderte Bits werden mit 1 belegt if((RegA_diff & (1<<PINA4)) != 0) // PA4 wurde verändert { if((RegA_neu & (1<<PINA4)) == 0) Auswahl=40; // PA4 ist low if((RegA_neu & (1<<PINA4)) != 0) Auswahl=41; // PA4 ist high } if((RegA_diff & (1<<PINA5)) != 0) // PA5 wurde verändert { if((RegA_neu & (1<<PINA5)) == 0) Auswahl=50; // PA5 ist low if((RegA_neu & (1<<PINA5)) != 0) Auswahl=51; // PA5 ist high } switch(Auswahl) { case 40: LEDaus(); Auswahl=0; InitKeys(); break; // PA4 low case 41: LEDein(); Auswahl=0; InitKeys(); break; // PA4 high case 50: SUMaus(); Auswahl=0; InitKeys(); break; // PA5 low case 51: SUMein(); Auswahl=0; InitKeys(); break; // PA4 high } }
Wie kann man aus einem ISR, einen Wert zurück geben, außer eine erneute volatile-Variable zu verwenden?
Euch ein angenehmes Wochenende
__________________________________________________ _
| Sprache: C | Teensy 3.2 | Arduino 2.x | Status: EwigerAnfaenger |
Gesetzt den Fall, Du schließt wirklich Taster an (DAS ist mir in Deiner Anwendung nicht ganz klar, Du schriebt, Du wolltest "erst einmal" Taster anschließen, ansonsten schriebst Du nur von "Kontakten"):
Die ATTinys setzen das Status-Flag des Port-Change beim Eintritt in die entsprechende ISR zurück. Sollte der Eingang danach noch im µs-Bereich "flimmern",
löst das schon während der laufenden ISR den nächsten Interrupt aus - nicht sofort, da beim Betreten einer ISR implizit das "global interrupt enabled"-Flag zurückgesetzt wird. Das gesetzte Statusflag wirkt aber sofort nach Verlassen der ISR (hier wird implizit auch wieder das "global interrupt enabled" gesetzt) und Dein Programm springt direkt wieder in die gleiche ISR. Das merkst Du z.B., wenn Du in Deiner ISR einen Zähler inkrementierst. Der springt dann mal zwei oder mehr Schritte pro Tastendruck, je nachdem, wie lange das Prellen dauert und wie schnell Dein ISR-Code abläuft.
Wenn Du im ms-Bereich über einen Timer einfach nur den Port abfragst, hast Du dieses Problem nicht. Das Abtasten der Pin-Zustände im zeitlichen Raster wirkt wie ein digitaler Tiefpass, der das Prellen oberhalb der halben Abtastfrequenz (siehe Nyquist- oder Shannon-Theorem) herausfiltert.
Geändert von Holomino (02.08.2019 um 16:43 Uhr)
Wenn du mechanische Schaltkontakte nutzt (die Prellen) ist es besser wenn du einen Timer zum Auslesen verwendest.
Ich hätte noch eine Verbesserung des Codes. Du prüfst mit einer If auf "0" und mit einer If auf "1". Bei einer If-Abfrage gibt es aber auch noch "else", das wird immer angesprungen wenn das If-Ergebnis nicht "1" ist.
Ein Beispiel als Pseudocode:
ist das gleiche wie:Code:if (PB3 == 1) { Led = 1 } if (PB3 != 1) { Led = 0 }
das ist auch das gleiche:Code:if (PB3 == 1) { Led = 1 } else { Led = 0 }
Das if wird immer ausgeführt wenn das Ergebnis wahr ist und das ist immer der Fall wenn es nicht 0 ist. Wenn du auf "0" abfragen willst musst du aber "if (Variable == 0)" schreiben. Bei der while Schleife ist es das gleiche, deswegen sind auch "while(1)" Schleifen endlos.Code:if (PB3) { Led = 1 } else { Led = 0 }
MfG Hannes
Interessanter Aspekt, da ich davon ausging, dass erst nach dem Verlassen der ISR der nächste Interrupt durchgelassen wird. Das "speichern" des Flag innerhalb eines ISR ist mir neu und macht einiges unübersichtlicher...
Daher wollte ich auch innerhalb des ISR die Tastenentpreller (später teils Tasten, Türkontakte, Bewegungsmelder, etc) einsetzen. Nach deiner Beschreibung, aber vollkommen unsinnig.
Hier habe ich immer noch "Bauchgrummeln", da auch ohne minuten-/stundenlange Kontaktbetätigung, im ms-Interval ISR-Routiniert wird - unnötige Energie und Rechenleistung!?
Wie sieht es mit einem Kompromiss als Königsweg aus?
Bsp:
PortChange-Interrupt löst den Timer-Interrupt aus, der diesen wiederum ablöst und eine Tastenentpreller einleitet. Erst danach DARF der "global interrupt enabled" des PortChange wieder gesetzt werden.
__________________________________________________ _
| Sprache: C | Teensy 3.2 | Arduino 2.x | Status: EwigerAnfaenger |
Löse Dich von dieser Vorstellung. Ohne Sleep-Modi (die eigentlich nur im Batteriebetrieb interessant sind) läuft der Controller in der main-Loop immer in der Runde. Da spart man nix. Die Verluste von Netzteil und Regler bewegen sich üblicherweise weit oberhalb der vom Controller aufgenommenen Leistung.
Der von mir gepostete ISR-Rahmen dürfte incl. Stack-Push/-Pop nicht mehr als 10..20µs bei 8MHz dauern. Im Zyklus von 1..8ms aufgerufen (so schnell muss man erst mal tippen können) und bezogen auf die Gesamtleistung des Controllers reden wir also über 0,125 .. 2% Rechenlast für die Timerroutine.
Hallo - nochmal.
Die Methoden die ihr mir mit dem Timer-ISR aufgezeigt habt ist toll und funktioniert. Soweit kann ich auch als Anfänger jede Code-Zeile nachvollziehen.
Hier ist es so, das alle Kontakte des Register A kontinuierlich abgefragt werden. Sobald eine Veränderung statt findet, wird dieser Kontakt auf Prellung überprüft.
Zum Entprellen wird einfach eine Variable hoch gezählt. Sollte 30ms keine Veränderung statt finden, ist dieser Kontakt entprellt!
Danach kommt der Befehl "tu was".
Aber ... eigentlich brauche ich eine Kontaktabfrage aus dem main() heraus.
Innerhalb des Prg-ablauf gibt es verschiedene Bereiche. Mal ist es wichtig Kontakt PA4 dauernd zu überwachen, wärend dessen mir Eingang PA5 vollkommen egal ist.
Erst wenn ich PA4 benötige, würde ich auf Veränderung und Entprellung abfragen.
Oder ich sehe vor lauter Bäumen den Wald nicht mehr...
__________________________________________________ _
| Sprache: C | Teensy 3.2 | Arduino 2.x | Status: EwigerAnfaenger |
Ich denke mal, es ist kein Problem, den Code so zu erweitern, dass Du auch aus der main() auf die Tasten reagieren kannst. Tatsächlich hatte ich die Änderungen hier schon reingeschrieben, dann allerdings wieder gelöscht - ganz einfach weil es jetzt gänzlich unterschiedliche Konzepte für unterschiedliche Anwendungen gibt (nix für Ungut, aber bei "ich bräuchte" von nem Youngster lohnt es sich manchmal zu hinterfragen, ob er es denn wirklich braucht).
Eine tastengesteuertes Displaymenü z.B. würde ich mit Funktionspointern zu erschlagen suchen. Andere logische Zusammenhänge eher mit einer einfachen StateMachine. Ob das dann allerdings immer in der main() liegt oder ebenfalls in der Timer-ISR, hängt alleine davon ab, wie lange der Ablauf der Aktionen ist. Eigentlich präferiere ich die Timer-ISR, weil sie sich ideal für mehrere "asynchone" Aufgaben eignet (Das ist zwar nicht wirklich asynchron, aber mit Prescalern kann man fabelhaft passende Abfragezyklen bauen und so die Rechenleistung optimal aufteilen). Die main() hebe ich mir dann gerne für niederpriorisierte Aufgaben auf.
Wir müssten jetzt also erst einmal darüber sprechen, was genau Du vor hast.
Berechtigungen
Zitieren
Lesezeichen