Hallo.
Ich möchte in einem einfachen Testaufbau auf einen Tastendruck
reagieren. ZB: Wenn PA0 betätigt wird, soll ein INT aufgerufen werden.
Ich habe jetzt soweit auch schon in der Reference Manual nachgeschaut,
jedoch verwirrt mich dort so einiges.
Meine bisherigen Codeschnipsel sind bis jetzt:
1
GPIOA->MODER&=~(1UL<<0);// PA0 -> GPIO INPUT
2
GPIOA->MODER&=~(1UL<<1);
3
4
//Sysconfig fuer INT bei Tastendruck
5
SYSCFG->EXTICR[0]&=~(1UL<<0);
6
SYSCFG->EXTICR[0]&=~(1UL<<1);
7
SYSCFG->EXTICR[0]&=~(1UL<<2);
8
SYSCFG->EXTICR[0]&=~(1UL<<3);
9
10
EXTI->RTSR|=(1UL<<0);// Auf steigende Flanke reagieren
11
EXTI->FTSR|=(1UL<<0);// Auf fallende Flanke reagieren^
12
13
NVIC_EnableIRQ(EXTI0_1_IRQn);
14
NVIC_SetPriority(EXTI0_1_IRQn,3);
Der Interrupt selbst:
1
voidEXTI0_1_IRQHandler(void){__NOP();}
Vielleicht kann mir ja der ein oder andere nen Tipp geben,
worauf generell dabei zu achten ist, bzw was aktiviert werden muss.
Bis jetzt funktioniert rein gar nix :(
Ich benutze das stm32f0discovery Board und KEIL.
Bisher sieht alles gut aus! Jetzt noch den Clock für den SYSCFG
einschalten und dann läuft es.
BTW: endlich mal einer, der nicht diese grässliche ST-Lib verwendet,
sondern im RefMan nachschaut. So soll es sein!
Schalter und Interrupt. Das sollte sich normalerweise ausschließen. Mach
lieber einen 10ms (oder 1ms) Systick und frag den Eingang zyklisch ab.
Damit ist dann auch eine definierte Entprellung möglich. Gleichzeitig
kann der selbe Code beliebig viele Tasten bearbeiten.
Jedenfalls solange es um mechanische und damit prellende Tasten geht.
Noch größerer Blödsinn ist es, das Prellen vorher über eine
RC-Kombination wegfiltern zu wollen und dann trotzdem Interrupts
auszulösen.
Fast jedes größere Projekt hat einen oder mehrere zyklischen Timer. Um
Rampen zu fahren, Verzögerungen zu steuern, Zeiten messen u.s.w. Alles
was mit Tasten- und Schaltern zu tun hat ist gut beraten sich da mit
einzuklinken.
Das vielleicht 40 Jahre alte Grundprinzip von SPS Steuerungen die
Vorgänge: "Eingänge abfragen, Programm abarbeiten, Ausgänge ausgeben"
zeitlich zu Schachteln hat sich nicht umsonst bis heute gehalten. Das
hatte auch zum Ziel, die Vorgänge die in der Regel Störungen durch
Funken erzeugen (Realis, Schütze schalten), zeitlich von der Abfrage der
Eingänge zu trennen.
old man schrieb:> Schalter und Interrupt. Das sollte sich normalerweise ausschließen.
Früher mal.....
old man schrieb:> Mach> lieber einen 10ms (oder 1ms) Systick und frag den Eingang zyklisch ab.
Du empfiehlst allen Ernstes pollen??? Sind wir noch in den 70-ern???
old man schrieb:> Damit ist dann auch eine definierte Entprellung möglich. Gleichzeitig> kann der selbe Code beliebig viele Tasten bearbeiten.
Geht mit INT + Timer genauso gut. Der Cortex M0 hat ja genug Timer. Und
jeder Pin kann einen INT generieren. Selbst die kleinen AVRs schaffen
das :-)
old man schrieb:> Noch größerer Blödsinn ist es, das Prellen vorher über eine> RC-Kombination wegfiltern zu wollen und dann trotzdem Interrupts> auszulösen.
Wenn aber dahinter ein Schmitt-Trigger-Eingang kommt (wie bei allen mir
bekannten Cortex-M0 übrigens), dann ist das nichts anderes als das hier:
http://www.mikrocontroller.net/articles/Entprellung#Einfacher_Tasterold man schrieb:> Fast jedes größere Projekt hat einen oder mehrere zyklischen Timer. Um> Rampen zu fahren, Verzögerungen zu steuern, Zeiten messen u.s.w. Alles> was mit Tasten- und Schaltern zu tun hat ist gut beraten sich da mit> einzuklinken.
Für die Entprellung: ja. Zum pollen: ganz sicher nein.
old man schrieb:> Das vielleicht 40 Jahre alte Grundprinzip von SPS Steuerungen die> Vorgänge: "Eingänge abfragen, Programm abarbeiten, Ausgänge ausgeben"> zeitlich zu Schachteln hat sich nicht umsonst bis heute gehalten.
Ja, bei SPS. NICHT in uC-Systemen! Dort erwartet der Benutzer meist eine
sofortige Reaktion auf den Tastendruck. Man stelle sich z.B. eine
Fernbedienung oder Handy vor, der mit 2 Sekunden (übertrieben)
Verzögerung arbeitet :-)
Ebenso witzig ist aber auch ein Endschalter, der wegen der
Programmausführung mechanisch überfahren wird. Weitere Beispiele kann
man sich leicht ausdenken.
old man schrieb:> Das> hatte auch zum Ziel, die Vorgänge die in der Regel Störungen durch> Funken erzeugen (Realis, Schütze schalten), zeitlich von der Abfrage der> Eingänge zu trennen.
Es gibt keine Funkenbildung in uC-Systemen, seit man auch die
EMV-Bestimmungen berücksichtigt (bzw. berücksichtigen muss). Mit einem
Snubber-NW bekommt man auch Relais relativ gut in den Griff. Wenn etwas
trotzdem so stark abstrahlt, dass es irgendwo störend einkoppelt, so hat
der HW-Entwickler Mist gebaut. Bisher ist mir aber noch keine Baugruppe
untergekommen, bei dem die Tastenabfrage (also etwas relativ langsames
und robustes) gestört worden wäre. Das Layout wird bei uns allerdings
auch von EMV-erfahrenen Entwicklern gemacht.
Zugegeben, in SPS-en sieht die Sache anders aus. Dort hat man eher auch
mit großen geschalteten Lasten / Schützen zu tun. Aber letztendlich ist
die Hardware des SPS auch daraufhin optimiert, mit allen Vor- wie auch
Nachteilen.
Dennis schrieb:> Du empfiehlst allen Ernstes pollen??? Sind wir noch in den 70-ern???
Auf Timer gestützte Tastenabfragen sind auch heute noch problemärmer als
Interrupts. Ausnahme: Der Tasten-Interrupt wird benötigt, um den µC aus
dem Schlaf zu reissen.
Dennis schrieb:> Ebenso witzig ist aber auch ein Endschalter, der wegen der> Programmausführung mechanisch überfahren wird. Weitere Beispiele kann> man sich leicht ausdenken.
Du hast Ahnung. Jahrzehntelang arbeiteten SPS mit Zyklenzeiten irgendwo
zwischen 1 und 10ms und das hat bei mechanischen Endschaltern immer
gereicht. Damit etwas mechanisch nicht überfahren werden kann, muss auch
die Mechanik schnell genug stoppen können. Da sind aber in der Regel
Wunschträume. Verfügst du über die Erfahrung das einschätzen zu können?
Weist du wie lang ein pneumatisches Magnetventil zum Abschalten braucht?
Du hast ja oben schön den Entprellartikel verlinkt. Komisch nur dass die
auch alle mit Timerinterrupts arbeiten und nicht mit flankengetriggerten
Interrupts der GPIOs. Glaubst du im Ernst bei einer Fernbedienung löst
jede Taste einen separaten Interrupt aus? Maximal einer für alle
zusammen um sie aus dem Tiefschlaf zu holen. Ansonsten sind das
gemultiplexte Tasten die zyklisch abgefragt werden.
> Ja, bei SPS. NICHT in uC-Systemen! Dort erwartet der Benutzer meist eine> sofortige Reaktion auf den Tastendruck. Man stelle sich z.B. eine> Fernbedienung oder Handy vor, der mit 2 Sekunden (übertrieben)> Verzögerung arbeitet :-)
Ich sprach hier von 1 bis 10ms. Das kannst du nicht mal als Echo hören
geschweige denn als Verzögerung einordnen. Um mit deiner RC-Kombination
sicher für einen mechanischen Schalter zu filtern, wir die Zeitkonstante
in einem ähnlichen Bereich liegen. Schon mal überlegt wie man 5
Drehencoder und 30 Tasten gleichzeitig behandelt? Auch da heißt das
Zauberwort Pollen.
GPIO-Interrups sind gut wenn sie vernünftig eingesetzt werden.
Hallsensoren an BLDC-Motoren sind ein gutes Beispiel. Aber mechanische
Schalter nicht.
Dennis schrieb:> Du empfiehlst allen Ernstes pollen??? Sind wir noch in den 70-ern???
Sind wir hier auf nem Wettbewerb um die ultimative Beleidigung a la
Monkey Island?
Also, für gewöhnliche Tasten ist "Pollen", also Abfrage im System-Tick
so alle 10 ms angesagt. Für Drehgeber gilt das oftmals nicht, siehe
entsprechende Hardware in einigen Controllern von NXP. Dort gibt es bei
Bedarf nen Interrupt.
Was lehrt uns dies? Nun, es lehrt uns, daß man nie mit dogmatischen
Vorurteilen ans Entwickeln gehen sollte, sonden Sinn und Grenzen für
verschiedene Lösungswegen kennen und abwägen sollte.
W.S.
