Cortex M0 Pin Interrupt

[CortexGast (Gast)]

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:

GPIOA->MODER &= ~(1UL<<0);    // PA0 -> GPIO INPUT
GPIOA->MODER &= ~(1UL<<1);

//Sysconfig fuer INT bei Tastendruck
SYSCFG->EXTICR[0] &= ~(1UL<<0);
SYSCFG->EXTICR[0] &= ~(1UL<<1);
SYSCFG->EXTICR[0] &= ~(1UL<<2);
SYSCFG->EXTICR[0] &= ~(1UL<<3);
  
EXTI->RTSR |= (1UL<<0);  // Auf steigende Flanke reagieren
EXTI->FTSR |= (1UL<<0);  // Auf fallende Flanke reagieren^

NVIC_EnableIRQ(EXTI0_1_IRQn);
NVIC_SetPriority(EXTI0_1_IRQn, 3);

Der Interrupt selbst:

void EXTI0_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.

[(prx) A. K. (prx)]

Ist das der gesamte Code? Immerhin muss man bei den STM32 alle 
verwendeten Komponenten erst einmal einschalten.

[CortexGast (Gast)]

Habe noch eine Zeile vergessen:

RCC -> AHBENR |= RCC_AHBENR_GPIOAEN;  //Clock PORTA -> EIN;

Ich hoffe mal, dass das alles war.
Mehr Code habe ich dazu auch nicht.

[(prx) A. K. (prx)]

Laut Ref gibts auch ein Bit um SYSCFG einzuschalten.

[Dennis (Gast)]

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!

[CortexGast (Gast)]

Super,

Hatte tatsächlich gefehlt:

RCC -> APB2ENR |= RCC_APB2ENR_SYSCFGEN;

Jetzt funktioniert es, DANKE!!

Dennis schrieb:
> So soll es sein!
Aber klaro :)

[old man (Gast)]

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.

[Dennis (Gast)]

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_Taster

old 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.

[(prx) A. K. (prx)]

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.

[old man (Gast)]

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.

[W.S. (Gast)]

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.