ATTiny per Taster wecken - Entprellung ?

[JH (Gast)]

Moin,

ich will einen ATTiny programmieren, der fast durchgehend schläft (Power 
Down). Drückt man einen Taster soll er aufwachen und einen 
Transistor/Relais anschalten, 3 Minuten an lassen, dann wieder 
ausschalten und wieder schlafen gehen.

Ich habe das ganze nun relativ naiv implementiert, d.h.:

-Ohne Entprellung
-Ohne Timer, sondern mit delay, da der uC in den 3 Minuten sowieso 
nichts anderes machen soll.

Hier der Code:

#define F_CPU 1200000UL

#include <avr/io.h>
#include <avr/sleep.h>
#include <avr/interrupt.h>
#include <util/delay.h>

#define BUTTON_PORT PB1
#define RELAIS_PORT PB4

#define RELAIS_ON (PORTB |= (1<<RELAIS_PORT))
#define RELAIS_OFF (PORTB &= ~(1<<RELAIS_PORT))

ISR(INT0_vect){
  
}

int main(void)
{
  //PB1 (Taste) als Eingang konfigurieren
  DDRB &= ~(1<<BUTTON_PORT);
  //PB1 (Taste) - PullUp aktivieren
  PORTB |= (1<<BUTTON_PORT);
  
  //PB4 (Transistor) als Ausgang konfigurieren
  DDRB |= (1<<RELAIS_PORT);  
  
  //Aktiviere INT0 (low level)
  MCUCR &= ~((1 << ISC01) | (1 << ISC00));
  while(1)
  {
     RELAIS_OFF;
     GIMSK |= (1 << INT0);
     set_sleep_mode(SLEEP_MODE_PWR_DOWN);
     sleep_enable();
     sei();
     sleep_cpu();
     /*
     SCHLAF
     */
     sleep_disable();
     GIMSK &= ~(1<<INT0);
     cli();
    
     RELAIS_ON;
     for(uint16_t i=0;i<1800;i++){
        _delay_ms(100);
     }
  }
}

Wird das so funktionieren, oder habe ich etwas grundlegendes übersehen ?

Gruß
Jan

[Jörg W. (dl8dtl) (Moderator)]

Schlechte Idee.

Es ist natürlich klar, dass man einen Interrupt zum Aufwecken braucht,
aber die ISR sollte dann sofort hingehen und den Interrupt wieder
abschalten.  Ansonsten bekommst du ziemlich schnell einen
"Interruptsturm".

Wie aufwändig man dann die tatsächliche Entprellung hernach noch
gestaltet, ist Geschmackssache, aber den Interrupt an einem Taster
sollte man wirklich nur zum Aufwecken benutzen.

[Uwe (de0508)]

Hallo Jan,

vor dem aktivieren eines Taster Interrupts würde ich noch das Flag INTF0 
löschen.

Warum? steht im Datenblatt des unbekannten AVR µC?

[Jörg W. (dl8dtl) (Moderator)]

Btw., gibt es einen Grund, warum du die Einzel-Makros nimmst und nicht
gleich ein sleep_mode()?

[Peter D. (peda)]

Jörg Wunsch schrieb:
> Btw., gibt es einen Grund, warum du die Einzel-Makros nimmst und nicht
> gleich ein sleep_mode()?

Weil sleep_mode() eine Race Condition enthält, d.h. mit etwas Glück 
landet man im Sleep-forever.
Bzw. beim Idle wundert man sich, warum Interrupts manchmal riesige 
Latenzen haben. Viel Spaß beim Debuggen.

Das sleep_disable() ist allerdings völliger Humbug, auch wenn es Atmel 
in jedem Datenblatt so schreibt.
Sleep wird nur durch den sleep_cpu() Befehl ausgeführt, ein Disable für 
den restlichen Code ist daher völlig ohne Effekt.

set_sleep_mode(), sleep_enable() muß man auch nicht vor jedem 
sleep_cpu() nochmal machen, einmal im Init nach dem Reset reicht völlig. 
Die Bits ändern sich nicht durch Geisterhand.

[Fred (Gast)]

Peter Dannegger schrieb:

> Weil sleep_mode() eine Race Condition enthält, d.h. mit etwas Glück
> landet man im Sleep-forever.


> Bzw. beim Idle wundert man sich, warum Interrupts manchmal riesige
> Latenzen haben. Viel Spaß beim Debuggen.

Kannst du die beiden obigen Punkte näher erläutern?

[Sandmännchen (Gast)]

Beitrag "EIN-AUS mit Taster per Interrupt, ATtiny25 o.ä."

[Peter D. (peda)]

Fred schrieb:
> Kannst du die beiden obigen Punkte näher erläutern?

Siehe sleep.h, Zeilen 73..104

[Jörg W. (dl8dtl) (Moderator)]

Peter Dannegger schrieb:
> set_sleep_mode(), sleep_enable() muß man auch nicht vor jedem
> sleep_cpu() nochmal machen, einmal im Init nach dem Reset reicht völlig.

Ja, wenn man es so herum implementiert, gebe ich dir völlig Recht.

Aber einfach nur das, was in sleep_mode() drin ist, als drei einzelne
Aufrufe direkt ersetzen, hat wenig Zweck.

Die Diskussion um die race condition kann man übrigens hier finden:

http://lists.gnu.org/archive/html/avr-gcc-list/2005-12/msg00085.html

[Peter D. (peda)]

Jörg Wunsch schrieb:
> Aber einfach nur das, was in sleep_mode() drin ist, als drei einzelne
> Aufrufe direkt ersetzen, hat wenig Zweck.

Macht er ja nicht.
Der feine Unterschied ist das sei() direkt vor dem sleep_cpu().

[JH (Gast)]

Moin und danke für die Antworten !

Ich deaktiviere den INT0 jetzt direkt wieder, um nicht den 
angesprochenen "Interruptsturm" zu bekommen.

#define F_CPU 1200000UL

#include <avr/io.h>
#include <avr/sleep.h>
#include <avr/interrupt.h>
#include <util/delay.h>

#define BUTTON_PORT PB1
#define RELAIS_PORT PB4

#define RELAIS_ON (PORTB |= (1<<RELAIS_PORT))
#define RELAIS_OFF (PORTB &= ~(1<<RELAIS_PORT))

ISR(INT0_vect){
  GIMSK &= ~(1<<INT0);
}

int main(void)
{
  //PB1 (Taste) als Eingang konfigurieren
  DDRB &= ~(1<<BUTTON_PORT);
  //PB1 (Taste) - PullUp aktivieren
  PORTB |= (1<<BUTTON_PORT);
  
  //PB4 (Transistor) als Ausgang konfigurieren
  DDRB |= (1<<RELAIS_PORT);  
  
  //Aktiviere INT0 (low level)
  MCUCR &= ~((1 << ISC01) | (1 << ISC00));
  
  //Aktiviere Sleep Mode
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  
    while(1)
    {
        RELAIS_OFF;
    GIMSK |= (1 << INT0);
    sei();
    sleep_cpu();
    cli();
    
    RELAIS_ON;
    for(uint16_t i=0;i<1800;i++){
      _delay_ms(100);
    }
    }
}

Wenn ich den Taster nun aber nicht entprelle, was kann denn dann 
passieren ? Ich rufe den Tasterstatus ja gar nicht mehr ab, sondern 
schalte sofort 3Min ein, sobald der Controller wieder wach ist. Gibts da 
Nachteile ?!

[Peter D. (peda)]

JH schrieb:
> Gibts da
> Nachteile ?!

Daß durch elektrostatische Entladungen (über Teppich laufen) die 
Schaltung anspricht, ohne daß die Taste gedrückt wurde.

[JH (Gast)]

Okay, habe jetzt dann doch noch deine Entprellroutine für einen Taster 
verwandt, da ich die Wartezeit eh mit einem Timer machen wollte.

Habe jetzt aber noch ein anderes Problem: Statt der ausgerechneten 3 
Minuten wird der Ausgang für ca. 3m20s gesetzt. Das Problem tritt auch 
auf, wenn ich statt des Timers einfaches naives delay wie oben verwende. 
Kann das am Takt liegen, oder liegt der Fehler im Programm ?!

Den Takt habe ich auf 4.8MHz und die CKDIV Fuse aktiviert.

[Jörg E. (jackfritt)]

Und warum steht bei F_CPU 600khz? Oder habe ich mich verguckt?

[JH (Gast)]

Naja 4.8MHz durch 8 aufgrund der CKDIV8 Fuse ergibt bei mir 600kHz..

[Jörg E. (jackfritt)]

Ah ok jetz habe ichs. Zu schnell überflogen.

[Route_66 H. (route_66)]

Hallo!
Warum nimmst Du für einen so übersichtlichen Algorithmus nicht einfach 
nur den RESET-Kopf? Nach Deinen drei Minuten kannst du dann den µC in 
den absoluten Tiefschlaf schicken. Die Reset-Beschaltung und die gefuste 
Startup-Time sorgen für eine wirksame Entprellung.

[JH (Gast)]

Moin,

die Schaltung steht nun schon und die Entprellung funktioniert ja auch 
ganz gut. Das oben beschriebene Problem mit der ungenauen Zeit besteht 
jedoch immer noch :(

Weiß da jemand Rat ?

[Konrad S. (maybee)]

JH schrieb:
> Statt der ausgerechneten 3
> Minuten wird der Ausgang für ca. 3m20s gesetzt.

Das ist eine Abweichung von ca. 10% und liegt bei vielen ATtinys 
durchaus im zulässigen Bereich.

Ändere einen der Werte (F_CPU, Endwert der Schleife, Delay-Wert) oder 
kalibriere den RC-Oszillator.