Polling oder Interrupt?

[M. I. (seventh_son)]

Hallo,

ich bin Einsteiger und überlege für ein Projekt, ob ich mit Polling oder 
Interrupt arbeiten soll.

Im Projekt geht es darum, RS232-Befehle an eine Temperaturregelung 
weiterzugeben, z.B. Einstellen einer Temp., Auslesen einer Temp., 
Einstellen von Modi und Parametern etc.

Also nicht unbedingt zeitkritische Anwendungen, und die Regelung muss ja 
sowieso erstmal reagieren und braucht dann etwas Zeit bis zum 
eingeschwungenen Zustand.

Wie würdet ihr das lösen? Ich tendiere zur Zeit zu Polling, weil mir 
diese Art der Steuerung einfach klarer und robuster erscheint.

Außerdem würden mich allgemeine Pro und Cons interessieren.

[Stefan (Gast)]

Hi,
ich persönlich finde die Nutzung von Interrupts prinzipiell sehr 
elegant.
Wichtig ist nur das die Interrupt Service Routine (ISR) die verwendeten 
Register sichert (push/pop). Außerdem solltest du unbedingt das SREG 
sichern und wieder herstellen wenn die ISR verlassen wird.
Schema z.B. für Timer1 overflow :
onTC1:  push  r16
  in  r16,SREG
  push  r16
 ;
 ; hier Deine Anweisungen
 ;

  pop  r16
  out  SREG,r16
  pop  r16
  reti

Alternativ zum (dauerhaften) persistent polling, wobei das Programm 
wartet bis das erwartete Ereignis eintritt, kannst du auch eine 
einmalige Abfrage machen (non persistent). Falls das Ereignis noch nicht 
eingetreten ist macht das Programm einfach weiter - villeicht klappt es 
dann im nächsten Durchlauf.
Damit hast du dann nicht einen so großen Zeitverzug.

Gruß
Stefan

[Dirk H. (arm-dran)]

M. I. wrote:
> Hallo,
>
> ich bin Einsteiger und überlege für ein Projekt, ob ich mit Polling oder
> Interrupt arbeiten soll.
>
> Im Projekt geht es darum, RS232-Befehle an eine Temperaturregelung
> weiterzugeben, z.B. Einstellen einer Temp., Auslesen einer Temp.,
> Einstellen von Modi und Parametern etc.
>
> Also nicht unbedingt zeitkritische Anwendungen, und die Regelung muss ja
> sowieso erstmal reagieren und braucht dann etwas Zeit bis zum
> eingeschwungenen Zustand.
>
> Wie würdet ihr das lösen? Ich tendiere zur Zeit zu Polling, weil mir
> diese Art der Steuerung einfach klarer und robuster erscheint.
>

In diesem Fall ist das auch so!
Bei Polling oder abscannen im Timerinterrupt (z.B) hast Du auch 
gleichzeitig die Möglichkeit einer TIMEOUT Überwachung.

> Außerdem würden mich allgemeine Pro und Cons interessieren.

[M. I. (seventh_son)]

@Dirk Hofmann

Du meinst den Watchdog? Wieso hätte ich diese Möglichkeit bei Interrupts 
nicht?

[Dirk H. (arm-dran)]

M. I. wrote:
> @Dirk Hofmann
>
> Du meinst den Watchdog? Wieso hätte ich diese Möglichkeit bei Interrupts
> nicht?

Nein ich meine nicht den Watchdog. Dieser schützt davor, wenn sich Ein 
System im Nirvana aufhängt.

Ich meine hier eine partielle Kontrolle der Pheripherie, die sozusagen
in einem "Aufwasch" erledigt wird. Dadurch bekommst Du auch ein
nachvollziehbares Timing für Reaktionszeiten.

Um dies jedoch zu beurteilen, solltest Du mal schildern, was Du genau 
pollen willst!?

[M. I. (seventh_son)]

Im Grunde geht es um das Pollen von RS232-Befehlen, also der 
UART-Receive muss abgefragt werden, um die Befehle dann in 
Steuerinformationen an den Regler umzusetzen.

Wenn z.B. der Befehl "Setze Temperatur auf X Grad" ankommt, muss im 
Regler eben diese Solltemperatur eingestellt werden.

[Karl H. (kbuchegg)]

Würde ich persönlich mit einer Kombination aus
ISR und Polling realisieren.

In der ISR wird das Zeichen von der UART geholt
und in einen Buffer gestellt. Ist das Zeichen das
vereinbarte End-eines-Befehls Zeichen (dafür
würde ich Return benutzen), dann setzt die ISR
ein Jobflag, dass eine Zeile komplett empfangen
wurde.

Das Polling geschieht in der üblichen main-Schleife.
Diese pollt unter anderem das Eine-Zeile-empfangen
Job Flag und wenn dieses signalisiert, dass eine Zeile
da ist, wird in der main-Schleife das Kommando ausgewertet.

char UARTLine[40];      // hier hinterlässt die ISR die empfangene
                        // Zeile
volatile uint8_t lineReceived;  // wird 1 wenn von der ISR
                                // ein CR empfangen wird


int main()
{
   ....

   while( 1 ) {

     if( lineReceived == 1 ) {
       // eine Zeile ist eingelangt, werte sie aus

       ....

       lineReceived = 0;
     }

     ....

   }
}

So ungefähr.

Oh, und die ISR ist natürlich der UART Receive Interrupt.

[M. I. (seventh_son)]

Danke für den Vorschlag.

Was mich etwas daran stört ist die Tatsache, dass bei jedem erhaltenen 
Zeichen der Interrupt ausgelöst wird. Eigentlich bräuchte ich den 
Interrupt ja nur, wenn ein kompletter Befehl mit Ende-Zeichen angekommen 
ist.

Da das Programm auch noch andere Routinen enthalten wird, die nicht 
durch RS232-Befehle gestartet werden, etwa eine Berechnung von 
Soll-Ist-Differenztemperaturen, funkt mir der Interrupt unter Umständen 
ständig dazwischen, obwohl der komplette Befehl noch gar nicht 
übermittelt ist.

Kann ja durchaus sein dass der Prozessor damit kein Problem hat, aber 
ich stelle es trotzdem mal zur Diskussion.

[Karl H. (kbuchegg)]

M. I. wrote:
> Danke für den Vorschlag.
>
> Was mich etwas daran stört ist die Tatsache, dass bei jedem erhaltenen
> Zeichen der Interrupt ausgelöst wird. Eigentlich bräuchte ich den
> Interrupt ja nur, wenn ein kompletter Befehl mit Ende-Zeichen angekommen
> ist.
>
> Da das Programm auch noch andere Routinen enthalten wird, die nicht
> durch RS232-Befehle gestartet werden, etwa eine Berechnung von
> Soll-Ist-Differenztemperaturen, funkt mir der Interrupt unter Umständen
> ständig dazwischen, obwohl der komplette Befehl noch gar nicht
> übermittelt ist.

Was ist dir lieber:
Das ein empfangenes Zeichen einen Interrupt auslöst und in
dieser ISR in 5 bis 10 Taktzyklen das Zeichen geholt und
zwischengespeichert wird oder wenn du ständig alle paar
Millisekunden die UART überprüfen musst ob nicht vielleicht
in der Zwischenzeit ein Zeichen eingetrudelt ist, dass zwischen-
gespeichert werden muss.

Die ISR wird nur dann aufgerufen, wenn auch wirklich ein
Zeichen über die UART eingetroffen ist. Da du die Kommandos
händisch eingibst, dürfte das ja nicht so oft der Fall sein.
Aus Sicht des µC vergeht zwischen 2 empfangenen Zeichen
allerdings eine halbe Ewigkeit.

[M. I. (seventh_son)]

Du hast schon Recht, abgefragt werden muss der UART ja so oder so.

Ich dachte, vielleicht gibt es eine Möglichkeit, erst den UART-Eingang 
zu verarbeiten wenn ein kompletter Befehl eingetroffen ist. Aber je mehr 
ich darüber nachdenke desto mehr merke ich, dass das Blödsinn ist ;)