Doppelter Einsprung in die ISR bei einem PCINT verhindern?

[M. G. (ixil96)]

Hallo!

Ich möchte detektieren, ob ein Ladestecker an meine Schaltung 
angeschlossen wird oder nicht.

Dazu verwende ich einen Spannungsteiler am Eingang und vom 
Spannungsteiler auf den PCINT des ATtiny44.

Wenn ich nun den Powerplug anstecke bzw. abstecke, wird die ISR manchmal 
2x ausgeführt obwohl ich in der ISR den PCINT und alle anderen Interupts 
für ca. 100ms sperre.

Was mache ich falsch?

ISR (PCINT0_vect)              // Charger connected
{
  GIMSK &= ~(1<<PCIE0);          // Disable PCINT [7:0]
  cli();                  // Alle Interrupts sperren
  
  if ( (chargerflag == 0) || (chargerflag == 99) )
  {
    chargerflag = 1;  
  }
  else 
  {
    chargerflag = 0;  
  }
}

[Peter II (Gast)]

m. g. schrieb:
> Was mache ich falsch?

Es geht so nicht, du musst das Signal vorher in Software oder Hardware 
en
prellen.

[Frank M. (ukw) (Moderator)]

m. g. schrieb:

> Wenn ich nun den Powerplug anstecke bzw. abstecke, wird die ISR manchmal
> 2x ausgeführt obwohl ich in der ISR den PCINT und alle anderen Interupts
> für ca. 100ms sperre.

Während die ISR läuft? Glaube ich nicht. Eine ISR im C-Runtimesystem 
sperrt automatisch alle Interrupts derart, dass ein zweiter 
zwischenzeitlich aufgetretener Interrupt erst nach Beenden der ISR 
zuschlagen kann.

Daher:

>

>   GIMSK &= ~(1<<PCIE0);   // grober Unfug, raus!
>   cli();                  // grober Unfug, raus!
>

Wie Peter schon schrieb: Dein Kontakt ist nicht entprellt. Mechanische 
Kontakte, die manuell geöffnet und geschlossen werden, prellen nunmal. 
Dabei ist es auch eine ziemlich schlechte Idee, die Wechsel über einen 
PCINT zu erfassen. Das führt meist zu einem Eigentor.

Tipp: Lektüre von Entprellung

[Chris L. (kingkernel)]

Du sperrst zwar die Interrupts für 100ms. Aber wenn in der Zeit was 
passiert, wird das trotzdem erkannt und das entsprechende Bit im IFR 
gesetzt. Wenn du nun die Interrupts wieder freigibst, werden alle in der 
zwischenzeit registrierten Interrupts ausgeführt

[Holger L. (max5v)]

Hast du mal versucht das Interruptflagregister zurückzusetzen?
Nach der Wartezeit von 100ms und vor dem erneuten aktivieren des 
Interruptes ?

GIFR |= ( 1 << INTF0 );

[Peter II (Gast)]

Holger L. schrieb:
> Hast du mal versucht das Interruptflagregister zurückzusetzen?
> Nach der Wartezeit von 100ms und vor dem erneuten aktivieren des
> Interruptes ?

warten in der ISR erzeugt nur noch neue Probleme

[Holger L. (max5v)]

Das steht dort auch nirgendwo, gewartet bzw. die gewünschte Zeit mit dem 
Timer zu erfassen wird natürlich in der Main erledigt.

[Peter II (Gast)]

Holger L. schrieb:
> Das steht dort auch nirgendwo, gewartet bzw. die gewünschte Zeit mit dem
> Timer zu erfassen wird natürlich in der Main erledigt.

dann kann er gleich dein Eingang In der Main Erfassung und braucht keine 
ISR mehr.

[Holger L. (max5v)]

Wäre irgendwie ziemlich blöd, schon alleine wegen einem möglichen 
Schlafmodus.

GIFR |= ( 1 << INTF0 ); Das war für INT0 nicht für PCINT : GIFR |= ( 1 
<< PCIF );

[Peter II (Gast)]

Holger L. schrieb:
> Wäre irgendwie ziemlich blöd, schon alleine wegen einem möglichen
> Schlafmodus.

aufwecken man immer noch mit der ISR - sie muss ja kein Inhalt haben

[Georg (Gast)]

m. g. schrieb:
> und alle anderen Interupts
> für ca. 100ms sperre.

Wenn die Ereignisse so selten sind, ist es eh am besten, den Eingang in 
einer Timerroutine zu erfassen, z.B alle ms oder auch nur alle 10 ms. 
Dann stellt sich die Frage überhaupt nicht mehr, und auch die 
Entprellung ist ziemlich trivial. Und der Controller kann sich 
anderweitig langweilen.

Georg

[Pandur S. (jetztnicht)]

Solche Probleme loest man durch eine genaue analyse. Indem man erst man 
einen PIN in der ISR wackelt und mit dem Oszilloskop gleichzeitig das 
externe signal misst

[Peter II (Gast)]

Oder D. schrieb:
> Solche Probleme loest man durch eine genaue analyse. Indem man erst man
> einen PIN in der ISR wackelt und mit dem Oszilloskop gleichzeitig das
> externe signal misst

was soll man da noch Analysen? Das Kontakte Prellen und der Code damit 
nicht sauber umgehen kann ist doch schon klar.

[Andreas B. (bitverdreher)]

Oder D. schrieb:
> Solche Probleme loest man durch eine genaue analyse. Indem man erst man
> einen PIN in der ISR wackelt und mit dem Oszilloskop gleichzeitig das
> externe signal misst

Nein, solche Probleme löst an durch nachdenken und lesen des 
Datenblattes.

Gruß
Andreas