Taster Abfrage trotz Warteschleife

[Daniel (Gast)]

Hallo,

Prozessor Attiny13, Sprache C

Ich habe ein Programm, welches zu Beginn einmal im Grunde in einer 
Warteschleife hängt, da es etwas ausgibt und dazwischen immer kurz 
warten muss.
Dies geschieht direkt nach main(), aber vor der Hauptschleife.

Der Benutzer kann aber mit einem Taster in das Programm eingreifen bzw. 
Sachen aktivieren, deaktivieren. Die Taster werden über eine 
Entprellroutine aber erst in Hauptschleife erkannt.
Ich hätte aber gerne, dass der Benutzer schon vor Beginn der 
Hauptschleife, also während der Warteschleife schon mit Tastenimpulsen 
interagieren kann.

Ist dies irgendwie möglich außer die Taster in einem Interrupt 
abzufragen?

Danke.

[Electronics'nStuff (Gast)]

Stell doch einfach mal dein Programm hier rein - da wird dir auch gerne 
geholfen.

[Falk B. (falk)]

@  Daniel (Gast)

>Ist dies irgendwie möglich außer die Taster in einem Interrupt
>abzufragen?

Sicher, siehe Multitasking. Aber warum nicht einfach die Interrupts 
VORHER freischalten und nutzen?

[Mikel M. (mikelm)]

du mußt doch nur während des Wartens, die Tasten abfragen. Eigentlich ne 
gute Zeit dafür, der Tiny hat ja eh nichts anderes zu tun :D
 Sollte es zeitkritisch sein, mußt du es eben entsprechend 
programmieren.

[Karl H. (kbuchegg)]

> welches zu Beginn einmal im Grunde in einer Warteschleife hängt,

delay_ms ist selten die Lösung, aber sehr oft das Problem.

[Daniel (Gast)]

Hallo Falk und die anderen,

vielen Dank für den Link mit dem Multitasking. Ich denke, das hilft :-)
Werde mir das mal genauer ansehen und auf meinen Fall versuchen 
anzuwenden.

Danke.

[Daniel (Gast)]

*
 
Multitasking Demo, zweiter Versuch
 
ATmega32 @ 3,6468 MHz
 
LED + 1KOhm Vorwiderstand an PB0
Taster nach GND an PA0
UART an RXD und TXD
 
*/
 
#define F_CPU 3686400
// Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!
#define BAUD 9600L          
 
#include "avr/io.h"
#include "util/delay.h"
 
// Berechnungen
// clever runden
#define UBRR_VAL  ((F_CPU+BAUD*8)/(BAUD*16)-1)  
// Reale Baudrate
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     
// Fehler in Promille 
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000) 
 
#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif
 
uint8_t taste_lesen(void) {
    if (PINA & (1<<PA0))
        return 1;
    else 
        return 0;
}
 
void led_blinken(uint8_t taste) {
    static uint16_t zaehler=0;
 
    if (taste) {
        if (zaehler>=999) {
            PORTB ^= (1<<PB0);
            zaehler=0;
        }
    }
    else {
        if (zaehler>=99) {
            PORTB ^= (1<<PB0);
            zaehler=0;
        }
    }
 
    zaehler++;
    _delay_ms(1);       // 1 ms warten
}
 
void uart_lesen(void) {
    uint8_t tmp;
    if((UCSRA & (1<<RXC))) {                // empfangenes Zeichen abholbereit im UART ?
        tmp = UDR;
        while (!(UCSRA & (1<<UDRE)));       // Warte auf freien Sendepuffer vom UART
        UDR = tmp;
    }
}
 
int main(void) {
    int8_t taste;
 
    // IOs initialisieren
    
    PORTA = 1;              // Pull Up für PA0
    DDRB  = 1;              // PB0 ist Ausgang
 
    // UART initialisieren
    
    UBRRH = UBRR_VAL >> 8;
    UBRRL = UBRR_VAL & 0xFF;
    UCSRB = (1<<RXEN) | (1<<TXEN);
    
    // Endlose Hauptschleife
 
    while (1) {
        taste = taste_lesen();
        led_blinken(taste);
        uart_lesen();
    }
}

Ich habe mir gerade obiges Beispiel aus dem Tutorial mal genauer 
durchdacht.
Dabei ist mir aufgefallen, dass in der Funktion led_blinken() immer 1ms 
gewartet wird, bis der Zähler bei >=999 bzw. >99 ist (also 1000ms oder 
100ms).
Allerdings hat das Programm bzw. die anderen Programmteile ja selbst 
auch eine Durchlaufzeit. So wird in Summe die Vielzahl der Durchläufe 
des Programms+die Wartezeit für das Leuchten der LEDs genommen oder bin 
ich falsch?
Das entspricht ja prinzipiell nicht dem Ursprungsprogramm mit 1000ms 
delay...

[Karl H. (kbuchegg)]

Daniel schrieb:

> Dabei ist mir aufgefallen, dass in der Funktion led_blinken() immer 1ms
> gewartet wird, bis der Zähler bei >=999 bzw. >99 ist (also 1000ms oder
> 100ms).
> Allerdings hat das Programm bzw. die anderen Programmteile ja selbst
> auch eine Durchlaufzeit. So wird in Summe die Vielzahl der Durchläufe
> des Programms+die Wartezeit für das Leuchten der LEDs genommen oder bin
> ich falsch?

Nein, bist du nicht.
Im Prinzip hast du recht.
Allerdings reden wir hier um ein paar µs pro Schleifendurchlauf. Bei 
1000 Durchläufen summiert sich der Fehler zu ~1 Millisekunde auf.
Kannst du tatsächlich mnit freiem Auge feststellen, ob das Blinken einer 
LED genau 1 Sekunde oder 1 Sekunde + 1 Tausendstel Sekunde lang ist?


Wenn du genaue Zeiten brauchst, taugen diese ganzen _delay_ms Ansätze 
sowieso nichts. Wie schon gesagt: _delay_ms ist oft nicht die Lösung, 
sondern das Problem.

[Daniel (Gast)]

Hallo,

nein, für diesen Anwendungsfall "LED" ist das für das Auge natürlich 
nicht erfassbar/messbar.
Ich wollte nur bestätigt haben, dass ich das Programm, so wie es da 
steht, richtig durchschaue.
Um es genaue zu machen, würde man wahrscheinlich die Zählvariable 
"zaehler" einfach entsprechend in einem Timer inkrementieren und bei 
entsprechendem Inkrement die Abbruchbedienung in der if-Anweisung 
setzen.

Danke.

[Falk B. (falk)]

@  Daniel (Gast)

>Allerdings hat das Programm bzw. die anderen Programmteile ja selbst
>auch eine Durchlaufzeit. So wird in Summe die Vielzahl der Durchläufe
>des Programms+die Wartezeit für das Leuchten der LEDs genommen

Ja.

>Das entspricht ja prinzipiell nicht dem Ursprungsprogramm mit 1000ms
>delay...

Muss es auch nicht, weil es nur ein einfaches Beipiel ist, bei dem es 
nicht auf die letzte Mikrosekunde ankommt.

[Karl H. (kbuchegg)]

Daniel schrieb:

> Um es genaue zu machen, würde man wahrscheinlich die Zählvariable
> "zaehler" einfach entsprechend in einem Timer inkrementieren und bei
> entsprechendem Inkrement die Abbruchbedienung in der if-Anweisung
> setzen.
>

Praktisch JEDES ernst zu nehmende Programm aus der realen Welt (also 
abseits von Tutorien) hat in irgend einer Form einen Timer als 
'Heartbeat'. In diesem Heartbeat wird zb die Tastenentprellung gemacht 
und er dient als Zeitbasis für das komplette Programm.
Das ist einfacher realisiert als viele glauben. Nur muss man sich halt 
mal mit Timern beschäftigt haben.


Der spingende Punkt bei diesem Multitasking Beispiel ist der: das man 
Aktionen aufteilt und nicht auf die Fertigstellung wartet. Darum gehts.